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 > (0,0,0,Z)** > 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. Roland ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
