On Tue, Aug 17, 2010 at 10:56 AM, Luca Barbieri <l...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev