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. 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 ? Best regards, Christoph ------------------------------------------------------------------------------ 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
