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

Jose Fonseca jfonseca at vmware.com
Mon Jun 17 10:16:28 PDT 2013



----- 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:
> 
> #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.

Jose


More information about the mesa-dev mailing list