[Mesa-dev] [PATCH 1/4] gallium: add resource normalization flags (v3)

[Alex Deucher]

On Tue, Aug 17, 2010 at 10:56 AM, Luca Barbieri <luca at luca-barbieri.com> wrote:
>> I don't see the need for this "any" flag -- if this is an internally
>> generated texture, the state tracker can query the driver, find out what
>> normalization it prefers, and then use that explicitly.
>
> It is for internal textures, where we need to ask for the ability to
> use it as a sampler view, but not ask for any specific normalization.
>
> If we had only SAMPLER_VIEW_$norm, there would be no way to express that.
>
>> Once we get around to creating a texture, is it going to get layed out
>> differently
>
> Yes, it's going to get laid out differently depending on whether we
> want to use normalized coordinates or not.
>
> On nv30 we have two layouts:
> 1. "Swizzled" or z-curve, only for power-of-two textures. Supports
> mipmaps and requires normalized coordinates.
> 2. Linear layout. Doesn't support mipmaps, doesn't support non-clamp
> wrap and requires unnormalized coordinates
>
> On nv40 we have two layouts with less restrictions:
> 1. "Swizzled" or z-curve, only for power-of-two textures.
> 2. Linear layout. Support mipmaps, but only with normalized coordinates.
> Normalized coordinates can always be used.
> Unnormalized coordinates can always be used, as long as there are no
> mipmaps and either the texture is POT or the wrap mode is clamp.
>
> Also, cube maps must be square POT and use normalized coordinates on
> both nv30 and nv40
>

Here's a rough idea on radeon hardware:

r3xx/r4xx
normalized coordinates only
NPOT textures supported
Limited clamp and mipmap support with NPOT textures

r5xx
normalized and unnormalized coordinates supported
NPOT textures supported
Limited clamp and mipmap support with NPOT textures
Limited clamp support with unnormalized coordinates

r6xx/r7xx
normalized and unnormalized coordinates supported
NPOT textures supported
Full clamp and mipmap support with NPOT textures
Limited clamp support with unnormalized coordinates

Alex

>> depending on whether it uses clamp vs wrap addressing?
> No, this does not happen on any known hardware.
>
> However, since we are already splitting unnormalized and normalized,
> and some hardware requires clamp mode for unnormalized, it seems
> cleaner to also split unnormalized according to wrap mode.
>
> We could however indeed only have PIPE_BIND_SAMPLER_VIEW_UNNORMALIZED
> and have a cap for non-clamp modes with unnormalized coords (only
> needed by OpenCL afaik).
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>