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

[Luca Barbieri]

> 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

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