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

[Luca Barbieri]

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

Yes, exactly.

> 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?
Not sure what you mean: rendering to a texture is managed as usual
with the rasterizer and viewport, which are setup in the same way
(except for a format flag for the render target layout and sizes
specified differently).

Basically nv30 apparently implements the bare minimum in hardware to
do plain old POT textures and ARB_texture_rectangle.
To do so, it implements a swizzled Z-curve layout for mipmapped POT
textures with normalized coordinates and a linear non-mipmapped layout
with unnormalized coordinates and limited wrap modes.

nv40 apparently supports all combinations except for unnormalized
coordinates with mipmapping (which OpenGL never asks for, but other
Gallium users could in principle do).
nv50 has flexible tiling for npot textures with unnormalized support
which solves everything (and probably drops the Z-curve layout in
favor of it, or at least the Gallium driver doesn't use it).

Without modifying fragment shaders or dynamically converting textures,
the only solution is to choose correctly at creation time.

Fragment shader hacks and dynamic texture relayout may (or better,
should) be added later but the hint may still be useful.