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

[Richard Sandiford]

Jose Fonseca <jfonseca at vmware.com> writes:
> ----- Original Message -----
>> On Sun, 2013-06-16 at 10:22 -0700, Jose Fonseca wrote:
>> 
>> > Ok. I think this patch series is sound from an implementation POV. I
>> > see no point in delaying further. We can tweak things afterwards if
>> > deemed necessary.
>> > 
>> > Lets squash the commits, rename the XYZW8888 formats to go from
>> > low->high bit, and commit this into master.

Thanks.

>> Just so I'm clear, when you say "go from low to high bit", you mean that
>> in the new format names the first component in the name maps to the
>> least-significant bits in memory, thus:
>> 
>> #if defined(PIPE_ARCH_LITTLE_ENDIAN)
>> #define PIPE_FORMAT_RGBA8888_UNORM PIPE_FORMAT_R8G8B8A8_UNORM
>> #elif defined(PIPE_ARCH_BIG_ENDIAN)
>> #define PIPE_FORMAT_RGBA8888_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
>> #endif
>>
>> If I have this correct I'll send out a corrected series so we can get
>> this landed.
>
> Yep. That seems correct to me.
>
>   PIPE_FORMAT_XYZW8888_UNORM goes from least to most significant bit in
> integer: uint32 color = (X << 0) | (Y << 8) | ...
>
>   PIPE_FORMAT_X8Y8Z8W8_UNORM matches memory ordering: uint8 color[4] =
> {X, Y, Z, W};
>
>> (The patch series as given plugs the XYZW8888 formats into enum
>> pipe_format; I think it'd be clearer to do the #define the other way
>> around at the end, as I have it above, since that way enum pipe_format
>> remains endian-independent.)
>
> I didn't want to nitpick any further than I already have so far, but I
> agree with you entirely.

What do you think about the alternative "util: big-endian fixes for
format generator" implementation of the python bits:

  http://lists.freedesktop.org/archives/mesa-dev/2013-June/040594.html

?  Would it be OK to use that instead of the original?  I have some
follow-up patches for things like the zs, 565 and 10/10/10/2 formats
that apply on top of that series.

Thanks,
Richard