----- Original Message -----
> Jose Fonseca <jfons...@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?
Yep, that sounds good. Separate reply shortly.
> 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
I will try to a least skim over them quickly
I haven't been able to keep up with email / todo things lately. I have too much
going on. I need to cut the number of things and spend less time on them. It's
easy for little things, but large reviews are particularly hard to slot in my
schedule -- risk of regression, a lot of effort put in, so a minimal ammount of
care and attention is necessary. But I can't afford to micro manage / nitpick
anymore
Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
