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

Richard Sandiford rsandifo at linux.vnet.ibm.com
Mon Jun 17 11:24:28 PDT 2013

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.


>> 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:
>> #elif defined(PIPE_ARCH_BIG_ENDIAN)
>> #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:


?  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.


More information about the mesa-dev mailing list