[Mesa-dev] [RFC] [PATCH 0/3] Make Gallium aware of GL_TEXTURE_RECTANGLE

Luca Barbieri luca at luca-barbieri.com
Wed Aug 11 11:34:22 PDT 2010

> 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
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?

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.

> I don't like changing pipe_resource::flags after a texture is created.
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.

> 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.

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?

More information about the mesa-dev mailing list