On Thu, Feb 25, 2010 at 12:39 PM, michal <mic...@vmware.com> wrote: > Roland Scheidegger wrote on 2010-02-24 15:18: >> On 24.02.2010 12:48, Christoph Bumiller wrote: >> >>> This wasn't a problem before because textures and samplers were >>> linked 1:1, but in view of the gallium-gpu4-texture-opcodes branch, >>> this coordinate normalization bit becomes a problem. >>> >>> NV50 hardware has that bit in the RESOURCE binding, and not the >>> SAMPLER binding, and you can imagine that this will lead to us having >>> to jump through a few annoying looking hoops to accomodate. >>> >>> As far as I can see, neither D3D10 nor D3D11 nor OpenGL nor CUDA have >>> sampler states that are decoupled from the texture, and which contain >>> a normalized coordinates bit, so it's worth considering not having it there >>> in gallium either. >>> >>> For OpenGL, unnormalized coordinates are only used for RECT textures, >>> and in this case it makes sense to make it a property of the texture. >>> >> >> I agree this is not sampler state, but I don't quite agree this should >> be texture state. >> This changes how texture coordinates get interpreted in the interpolator >> - in that sense it is similar to the cylindrical texture coord wrap >> which we moved away from sampler state recently. This one got moved to >> shader declaration. I wonder if the normalization bit should be treated >> the same. >> Though OTOH you're quite right that in OpenGL this really is texture >> property (it is a different texture target after all), and afaik d3d >> doesn't support non-normalized coords (?). Hmm... >> >> > Isn't it the case that for RECT targets we clear the bit, and for others > we always set it? > > In mesa st I see: > > if (texobj->Target != GL_TEXTURE_RECTANGLE_ARB) > sampler->normalized_coords = 1; > > By definition, RECT texture with normalised coordinates is just an NPOT. > If we removed this apparently redundant flag, would that make nouveau > developers life easier? >
FWIW, r3xx-r5xx always requires normalized coords, the normalization is currently done in the shader. On r6xx+, you can specify normalized or non-normalized coords in the tex instructions. Alex >> >> >>> And, finally, I've seen you reverted the changes for independent image >>> and sampler index in the texture opcodes. What's up with that ? >>> Is the code not nice enough, or has the idea been discarded and by problem >>> disappears ? >>> >>> > > Please consider this branch dead. It will be easier for me to introduce > new, optional sampler and fetch opcodes a'la GL 3.0. There's just too > much code to fix and test and we still want the older hardware not to > stand on its head to try and translate back to old model. > > Thanks. > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
