[Mesa-dev] [RFC] [PATCH 0/2] Allow mesa/st to inform driver of GL_TEXTURE_RECTANGLE

[Roland Scheidegger]

On 15.04.2010 09:36, Luca Barbieri wrote:
> See also the RFC-gallium-unnormalized-coords-hint branch.
> 
> Currently the Gallium driver has no way of telling that a texture was created
> with GL_TEXTURE_RECTANGLE as opposed to GL_TEXTURE_2D.
> 
> Unfortunately, some hardware like nv30 has two texture layouts, and the
> first only works with unnormalized coordinates (and has no mipmap support),
> and the second only works with normalized coordinates (and requires POT sizes).
> 
> Thus, it is beneficial to know which kind of coordinates are going to be used at
> texture creation time.
> 
> Fortunately, with OpenGL, whether normalized or unnormalized coordinates can
> be used is decided at creation time, but we don't currently pass this to
> the driver.
> 
> This branch adds a new resource flag that is used by the state trackers to
> tell the driver whether it is going to typically use sampler states with
> normalized_coords = 0.
> 
> In practice, the OpenGL state tracker sets it if and only if GL_TEXTURE_RECTANGLE
> is being used as the texture target.
> 
> Note that this patch series does *not* make this a mandatory flag, but rather an
> hint: the driver is theoretically supposed to either change the texture layout
> or alter the fragment shader if a normalization mismatch happens.
> 
> The general idea is that the weird pre-DirectX 10 restrictions for texture sizes
> should be hidden by the driver, and not exposed to the state tracker.
> 
> Currently the NPOT cap exposes them a bit, but r300g just lifted all restrictions
> and hopefully nv30 will too (nv40 also has the minor restriction of not supporting
> unnormalized coordinates with mipmaps).
> 
> However, this flag is still likely to be useful to avoid unnecessary overhead.
> 
> Right now, it's required to correctly support ARB_texture_rectangle on nv30.
> 
> The impact on Gallium is quite minimal.

So, since one layout requires pot sizes, I guess the problem you have is
if a texture rectangle just happens to be POT you don't know that in the
driver upon texture creation time?
It's quite common for hw to have different layouts for pot and npot,
though normally they don't tie normalized vs non-normalized coordinates
to it... Seems like an odd choice, so if you do render to texture (to a
npot size) then you need to adjust the fragment shader for the
non-normalized texture coords?
Your solution looks acceptable to me, since drivers are free to ignore
that flag, though maybe someone else has objections.

Roland