----- Original Message -----
> Hi Jose,
>
> Thanks for the review.
>
> Jose Fonseca <jfons...@vmware.com> writes:
> > ----- Original Message -----
> >> From: Richard Sandiford <r.sandif...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
