<div class="gmail_quote">On Wed, Aug 11, 2010 at 8:34 PM, Luca Barbieri <<a href="mailto:luca@luca-barbieri.com">luca@luca-barbieri.com</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div class="im">> I agree that if a texture was created as GL_TEXTURE_RECTANGLE, meaning that > all shaders use the TGSI_TEXTURE_RECT sampler type, it makes sense to use > unnormalized coordinates. However if a texture is NPOT as in OpenGL, meaning > that all shaders use the TGSI_TEXTURE_2D sampler type, we shouldn't force > unnormalized texture coordinates everywhere and trade effectivity and > simplicity of one driver (nvfx/nv30) at the expense of another (r300). Also </div>The only change to r300g would be a single line to set the flag off. Why would this be a problem? Am I missing something? </blockquote><div> No, it's not a problem, though I'd like you to use TGSI_TEXTURE_RECT in shaders when appropriate to be Radeon-friendly (I am talking about r300 up to r700 here). </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Note that for ARB_texture_non_power_of_two textures, there would be no changes, since the state tracker won't ask for unnormalized coordinates and thus the flag won't be set, unless the driver decides to set it itself because it always prefers unnormalized coordinates. In general, only drivers that actively prefer one normalization would need to take action, in the form of advertising that by setting the flag on the texture. <div class="im"> > I don't like changing pipe_resource::flags after a texture is created. </div>It seems a good idea though to let the driver have a say on how u_blitter/u_blit should specify coordinates. Otherwise, they can't possible behave optimally on both nv30 and r300, which have opposing needs. And since it depends on the texture layout, a cap won't work. <div class="im"> > Some time ago I think Brian suggested to add PIPE_TEXTURE_RECT as another > texture type and make it match the meaning of GL_TEXTURE_RECTANGLE. We would > do this change but we had no time back then. This seems to be the solution > that would work best for everybody. </div>I think this would require extensive changes due to all the places that check for PIPE_TEXTURE_2D, and unduly burdens modern hardware (nv50+, r600+) which doesn't really care, since it supports everything orthogonally (BTW, note that OpenCL even requires to be able to mix&match samplers and sampler views in the shaders). It seems best to minimize the impact of this legacy behavior as much as possible. Is there any other factor that would balance all these disadvantages of introducing PIPE_TEXTURE_RECT? </blockquote></div> Because all nvidia hardware seems to have the normalized bit as a property of a resource (PIPE_TEXTURE_RECT or a flag would be okay here), and all ATI hardware has the normalized bit as part of the texture instruction (it's a shader state, so a driver looks for TGSI_TEXTURE_RECT), I believe it would really be best for everyone to have this RECT texture target type and removing normalized_coords from pipe_sampler_state. Luca, you've already done some work for this change. If you don't have time to finish PIPE_TEXTURE_RECT, I'll do that. -Marek