Results 1 to 2 of 2

Thread: Pixel formats and types and endian

  1. #1
    Newbie
    Join Date
    Aug 2013
    Posts
    6

    Question 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.

    {RGBA, GL_UNSIGNED_SHORT_4_4_4_4, BIG_ENDIAN} ==
    {ABGR, GL_UNSIGNED_SHORT_4_4_4_4_REV,BIG_ENDIAN} ==
    {BARG, GL_UNSIGNED_SHORT_4_4_4_4, LITTLE_ENDIAN} ==
    {GRAB, GL_UNSIGNED_SHORT_4_4_4_4_REV,LITTLE_ENDIAN} ==
    RRRRGGGG (first byte)
    BBBBAAAA (second byte)

    RRRRGGGGBBBBAAAA (big endian)
    BBBBAAAARRRRGGGG (little endian)

    Can you help me make some sense out of this?

  2. #2
    Super Moderator
    Join Date
    May 2008
    Posts
    27
    Quote Originally Posted by kturkowski View Post
    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.

    Quote Originally Posted by kturkowski View Post

    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.

    Quote Originally Posted by kturkowski View Post
    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.

    Quote Originally Posted by kturkowski View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •