[Mesa-dev] [PATCH 03/13] gallium: Introduce 32-bit bytewise format names

[Michel Dänzer]

On Die, 2013-05-21 at 23:15 -0700, Jose Fonseca wrote:
> 
> ----- Original Message -----
> > Jose Fonseca <jfonseca at vmware.com> writes:
> > > ----- Original Message -----
> > >> From: Richard Sandiford <r.sandiford at uk.ibm.com>
> > >> 
> > >> RGBA8888 has R at byte 0 and A at byte 3, regardless of platform
> > >> endianness.
> > >
> > > Maybe I'm missing something, but this naming convention seems to me
> > > the exact opposite of what was decided [1], which is:
> > >
> > >  - R at byte 0, ..., and A at byte 3, regardless of platform endianness
> > >  would be called "R8G8B8A8"
> > >
> > >  - R at bit 0, ..., A at bit 24, encoded as integers that match the
> > >  platform endianness would be called "RGBA8888"
> > >
> > > which would be consistent with (as in a superset of) D3D10 format
> > > naming.
> > 
> > Yeah, it's supposed to be that way round in the patches.  RGBA8888 is a
> > 32-bit int with R in the high 8 bits and A in the low 8 bits. 
> 
> This is still slightly different than what I expected: gallium was
> using the convention the components started with least significant bit
> appear first in name (same as D3D10). That is, RGBA8888 is a 32-bit
> int with R in the _low_ 8 bits and A in the _high_ 8 bits.
> 
> I understand that Mesa formats follow the opposite convention, but
> between consistency with Mesa vs consistency within gallium I believe
> that it is better for gallium formats to be consistent among
> themselves: it is much easier to remember that _all_ gallium formats
> go from least->most significant bit/byte/word, than to remember which
> formats are supposed to go from the low->high vs high->low, which
> would end up forcing developers to either guess wrongly or waste time
> look up the format implementation.

I disagree. There is no need or point to even think in terms of
least/most significant anything (implying a certain byte order) for
formats such as R8G8B8A8. They're just arrays.

For packed formats such as RGBA8888, the order used in these patches
(which is what I suggested in my proposal) matches the order humans use
for digits of numbers, as well as the Mesa formats. That seems more
important to me than 'matching' any non-packed formats (which only makes
sense if one presumes little endian byte order).


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer