[Mesa-stable] [Mesa-dev] [PATCH v2 2/2] mesa: _mesa_format_convert should be endian agnostic

[Ilia Mirkin]

On Sat, Aug 8, 2015 at 12:08 AM, Rob Clark <robdclark at gmail.com> wrote:
>
> On Fri, Aug 7, 2015 at 8:11 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
> > On Fri, Aug 7, 2015 at 12:24 PM, Oded Gabbay <oded.gabbay at gmail.com> wrote:
> >> This patch fixes a bug that is manifested in the read path of mesa when
> >> running on big-endian machines. The effects can be seen when running
> >> piglit sanity test and/or taking a screen capture.
> >
> > piglit sanity isn't all that convincing.  It's quite possible that
> > there are two byte-swapping bugs that just happen to cancel out.  If
> > it fixes huge numbers of piglit tests, that's more convincing.
>
> well, if sanity fails, basically all piglit tests would fail..
>
> that said, I'm a bit uncertain about how actual-hw gpu's deal w/ b/e..
> ie. do they swap everything around in the driver, or do we really need
> a concept of "gpu"[1] endianess vs cpu endianess in mesa?
>
> [1] where "gpu" endianess would be same as cpu endianess for swrast..
> but potentially different for !swrast..

It's all unfortunately pretty confused. Many GPUs (e.g. nvidia) allow
you to e.g. not have to byteswap the command stream and mmio writes
via a global "endian" register, but deep down inside, they remain LE.
So data uploads via the command stream are "ok" (since they get
implicitly byteswapped), but the ones via dma are not. These are all
situations the the general mesa library is just not prepared for. I
don't think there's clarity about whether the "hw" is supposed to be
same-endian as CPU or not, and all of the checks are obviously around
CPU endianness, which might implicitly mean that they expect the GPU
endianness to be different. (But probably not always, e.g. rgb10_a2
type things which have a fixed bit layout.)

At least as far as nouveau is concerned, no one has been seriously
paying attention to these issues, afaik GLX is completely fubar'd with
recent mesa versions (no fbconfigs found). Pre-mesa 9.2 it all worked
fine, mesa 9.2 broke all hw drivers (but made llvmpipe work) by
causing it to end up with swapped colors. There were some fixes sent a
while ago that were largely overlooked, and I guess the situation has
deteriorated further. IIRC Michel sent (and hopefully pushed) some
patches that (semi?) made it work for him. BE hardware is not easy to
come by, and obviously none of the core hw mesa developers have access
to it (otherwise it wouldn't be so broken), so personally I'd be happy
to just apply patches that make things work for someone, as long as
they don't obviously break the LE case.

  -ilia