Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 4 of 4

Thread: REV external formats

  1. #1
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,321

    REV external formats

    I'd like to confirm something I think I'm seeing in the spec and in driver behavior:

    Code :
    ORDER     FORMAT    TYPE
    -------- ---------- -----------
    RGBA      RGBA      UNSIGNED_BYTE
    RGBA      RGBA      UINT_8_8_8_8_REV
    BGRA      BGRA      UNSIGNED_BYTE
    BGRA      BGRA      UINT_8_8_8_8_REV
    ABGR      RGBA      UINT_8_8_8_8
    ARGB      BGRA      UINT_8_8_8_8

    Is this correct, if "ORDER" is the resulting memory order on a little-endian system (with GL_{PACK,UNPACK}_SWAP_BYTES = FALSE).

    If so, I guess I'd always misunderstood the REV types. REV = reversed in memory, and non-REV = not reversed. Right?

    ...no, I'm thinking it's not that simple. The non-REV types are laid out packed from msb -> lsb in the register, and then on little-endian the bytes are reversed when the word is written to memory. Same for REV types, except those are packed lsb -> msb in the register first.

    So for instance, RGBA/UNSIGNED_INT_8_8_8_8 is

    msb ----> RGBA <----- lsb

    in the register, and then when written to memory, it's flipped to:

    low address ---> ABGR <---- high-address.

    So in this RGBA8 case (with type = UNSIGNED_INT_8_8_8_8*), REV is "not" byte reversed in memory (RGBA stays RGBA), while non-REV "is" byte-reversed in memory (RGBA becomes ABGR).
    Last edited by Dark Photon; 06-21-2017 at 05:57 AM.

  2. #2
    Senior Member OpenGL Guru
    Join Date
    Jun 2013
    Posts
    2,722
    Quote Originally Posted by Dark Photon View Post
    So in this RGBA8 case (with type = UNSIGNED_INT_8_8_8_8*), REV is "not" byte reversed in memory (RGBA stays RGBA), while non-REV "is" byte-reversed in memory (RGBA becomes ABGR).
    OpenGL 4.5 core profile specification, 8.4 (Pixel Rectangles), table 8.8 on p188.

    Non-REV formats have the first component in the highest bits and the last component in the lowest bits, while REV formats are the the other way around.

    So for 8_8_8_8, the REV/non-REV distinction corresponds to a big-endian architecture, i.e. 8_8_8_8_REV is byte-swapped on big-endian architectures, 8_8_8_8 is byte-swapped on little-endian architectures.

    This might be a consequence of IRIX being big-endian. Or it might just be coincidence; the notion of packed formats being "byte-swapped" or not is only meaningful for 8_8_8_8; the other packed types don't have a 1:1 mapping between fields and bytes (well, technically "octets", but I don't think there's ever been an OpenGL implementation for architectures with other byte sizes).

  3. #3
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,321
    Ok, thanks for the confirmation.

  4. #4
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,321
    In order to prevent similar confusion in the future, I've updated the:


    page to better describe the how component and byte ordering works with format, type, *BYTE_ORDER, and client endianness (with examples).
    Last edited by Dark Photon; 06-20-2017 at 07:56 PM.

Posting Permissions

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