On 01.02.2010 20:23, Brian Paul wrote:
> Speaking of texture formats and texture sampling, one area of Gallium
> that's under-specified is what (x,y,z,w) values are returned by TEX
> instructions when sampling from each of the various texture formats.
> A while back I started a table comparing OpenGL to D3D:
> texture components OpenGL D3D
> R,G,B,A (R,G,B,A) (R,G,B,A)
> R,G,B (R,G,B,1) (R,G,B,1)
> R,G (R,G,0,1) (R,G,1,1)
> R (R,0,0,1) (R,1,1,1)
> A (0,0,0,A) (0,0,0,A)
> L (L,L,L,1) (L,?,?,1) (probably L,L,L,1)
> I (I,I,I,I) (?,?,?,?)
> UV (0,0,0,1)* (U,V,1,1)
> Z (Z,Z,Z,Z) or (0,Z,0,1)
> (Z,Z,Z,1) or
> other formats? ... ...
AL. Should be (L,L,L,A) for both OGL And D3D. And yes, (L,L,L,1) is
correct for D3D (that's what i965 at least does). There are no intensity
textures in d3d (unless you can somehow support that via cap bits, but
in that case I'd certainly expect it to be (I,I,I,I)).
UV is of course really odd in OGL, since it says the sample result is
constant but of course you still use the UV components for the bump
target. That's just an oddity to make that fit somehow into fixed
function pipeline rather than it has anything to do with hardware.
Note that the D3D column is only valid for DX9 (and older). DX10 uses
the same mappings as OpenGL (if it supports the format, all luminance,
alpha etc. textures are gone, as are the swizzled bgra formats).
> * per http://www.opengl.org/registry/specs/ATI/envmap_bumpmap.txt
> ** depends on GL_DEPTH_TEXTURE_MODE state
> For OpenGL, see page 141 of the OpenGL 3.1 spec.
> For D3D, see http://msdn.microsoft.com/en-us/library/ee422472(VS.85).aspx
> We should first add a column to the above table for Gallium and then
> decide whether to implement swizzling (and GL_DEPTH_TEXTURE_MODE) with
> extra GPU instructions or new texture/sampler swizzle state.
But most gpus can do arbitrary swizzling natively, hence inserting gpu
instructions really must be optional. Even hardware which can't do
arbitrary swizzling can sometimes do both OGL and D3D mapping, hence we
don't really want additional instructions there neither (i965 being the
example, though it's not easy to switch behavior, since that affects not
only the format of the border color too but also how the border color is
used if the particular channel isn't in the texture).
I think we'd want DX10/OGL behavior, and u_format defines it that way.
Except for depth/stencil formats, where the depth always ends up in the
red channel and stencil in green (with the rest undefined).
i965 actually has different depth/stencil formats (a24x8, l24x8, i24x8)
just for those depth texture modes (though the code suggests it won't do
anything if shadow comparison is enabled).
Or maybe we'd want additional formats just for DX9 - sounds like
overkill though. The different border color interpretation of i965
suggests to me that won't do much on its own for conformance anyway.
I think the swizzle values used by u_format are nice. Using xyzw rather
than rgba to refer to the first, etc. channel avoids confusion. Hence
I'd propose we'd use the same for the hypothetical sampler swizzle state
(that is x,y,z,w,0,1, not sure if the _ undefined makes sense there).
The swizzling would be the same as that indicated in u_format for all
textures initially, except depth/stencil.