Jose Fonseca wrote:
I read the extension and it is not crystal clear, but it seems to imply the swizzles are orthogonal to the format, and applied as the very last step before being used in a shader. That is, the semantics are the same of adding a swizzle instruction after a TEX opcode, regardless of the format. At least this is my interpretation of
The values of the texture parameters TEXTURE_SWIZZLE_R_EXT,
TEXTURE_SWIZZLE_G_EXT, TEXTURE_SWIZZLE_B_EXT, and
TEXTURE_SWIZZLE_A_EXT, are applied after the swizzling described
in Table 3.20 (p. 186). The swizzle parameter
TEXTURE_SWIZZLE_R_EXT affects the first component of Cs as:
Correct.
BGRA extension does not specify additions to the 3.20 table though (it's
against spec 1.1) so this is why the guess work.
So my expectaction is that swizzling a BGRA with a .rgba swizzle will get bgra.
Mmm, I don't think so.
Regardless of the original user texture component ordering and
regardless of the actually hardware texture format, when the shader
calls texture2D(sampler, coord), for example, it _always_ returns a
vector of (R, G, B, A) in that order. Similarly for ARB_vp/fp and
fixed-function texture sampling.
We'd have a miserable time writing shaders if we texture2D(sampler,
coord) returned different component orderings depending on the actual
texture format (which could vary from one system to another).
An extenstion like GL_EXT_bgra is used to describe the incoming/user
texture data to glTexImage2D, nothing about the internal/actual
texture layout.
-Brian
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
