The Khronos Group - a non-profit industry consortium to develop, publish and promote open standard, royalty-free media authoring and acceleration standards for desktop and handheld devices, combined with conformance qualification programs for platform and device interoperability.

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Hybrid View

Pixel formats and types and endian

I assume that when using RGBA with UNSIGNED BYTE, that the byte ordering is identical whether on a big or little endian system.
RRRRRRRR
GGGGGGGG
BBBBBBBB
AAAAAAAA
Similarly with BGRA. Right?

The difficulty comes when using components that are sub-byte,
i.e. GL_UNSIGNED_SHORT_4_4_4_4, GL_UNSIGNED_SHORT_5_5_5_1, GL_UNSIGNED_SHORT_5_6_5.
My understanding is that the components are packed big-endian into the native-endian SHORT, right?

Now, when a LITTLE_ENDIAN CPU is talking to a BIG_ENDIAN GPU, it seems that the pixel formats are different, e.g. for
{RGB, GL_UNSIGNED_SHORT_5_6_5, LITTLE_ENDIAN}
RRRRRGGGgggBBBBB
appears in the byte order
gggBBBBB
RRRRRGGG
which looks like
gggBBBBBRRRRRGGG
on a big endian machine. What is this format called on a big-endian machine? My understanding is that the _REV causes components to be packed from the little end, rather than the default big end, right? So _REV does not fix this up, right?

It is easier when an integral number of components fit into a byte, i.e.

I assume that when using RGBA with UNSIGNED BYTE, that the byte ordering is identical whether on a big or little endian system.
RRRRRRRR
GGGGGGGG
BBBBBBBB
AAAAAAAA
Similarly with BGRA. Right?

This has nothing to do with endianness. The spec says that the elements of a group (e.g. RGBA) are fetched one at a time from memory and it specifies the order in which they are fetched. It is indeed always R,G,B,A for RGBA format textures.

Originally Posted by kturkowski

The difficulty comes when using components that are sub-byte,
i.e. GL_UNSIGNED_SHORT_4_4_4_4, GL_UNSIGNED_SHORT_5_5_5_1, GL_UNSIGNED_SHORT_5_6_5.
My understanding is that the components are packed big-endian into the native-endian SHORT, right?

Table 3.6 (in the ES 2.0 spec.) shows the 1st component is packed in the most significant bits followed by the 2nd, 3rd and 4th. It says nothing else. I am pretty sure therefore that the ordering in memory has to vary according to the native endianness such that "most significant bits" always holds true.

Originally Posted by kturkowski

Now, when a LITTLE_ENDIAN CPU is talking to a BIG_ENDIAN GPU, it seems that the pixel formats are different, so that fetches from memory comply with the specification.

In this case the driver must perform any necessary re-ordering such that the requirements of the specification are followed.

Originally Posted by kturkowski

My understanding is that the _REV causes components to be packed from the little end, rather than the default big end, right? So _REV does not fix this up, right?

_REV reverses the order in which components are fetched from memory. Whereas the normally the GL fetches the 1st component from the MSB, _REV causes it to fetch the first component from the LSB and the 3rd or 4th component from the MSB of the native endian word.