On Die, 2013-05-21 at 23:15 -0700, Jose Fonseca wrote: > > ----- Original Message ----- > > 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.
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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
