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

[Marek Olšák]

On Wed, Aug 11, 2010 at 8:34 PM, Luca Barbieri <luca at luca-barbieri.com>wrote:

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

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


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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20100811/3b420b27/attachment.html>