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

[Jose Fonseca]

----- Original Message -----
> Hi Jose,
> 
> Thanks for the review.
> 
> 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.

> R8G8B8A8 is
> an array of 4 bytes in the order { R, G, B, A }.  I think it was just
> the comment in the covering note that had it the wrong way around --
> sorry about that.

Otherwise looks good.  I went through the implementation in more detail and it looks AFAICT.

As Adam mentioned on the cover email, the series must be squashed when commited, such way that each commit builds and works, to avoid interfering with git bisection.

I also agree with Marek regarding docs. Please create a new src/gallium/docs/source/format.rst and put a couple of paragraphs there on the differences between the two kinds.

Jose