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

[Roland Scheidegger]

On 15.04.2010 19:07, Luca Barbieri wrote:
>> 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).
I meant if you later use that same texture as a ordinary texture. I
guess though maybe that's not that often done with npot textures (well
for this generation of chips at least).


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

Agreed.

Roland