[Mesa-dev] gallium endianness and hw drivers

[Michel Dänzer]

On Mon, 2013-12-16 at 17:05 +1000, Dave Airlie wrote:
> So the llvmpipe endian work broke the nouveau nv40 support for the
> nv43 in the ppc G5 a few people have,

Same for r300g: https://bugs.freedesktop.org/show_bug.cgi?id=71789


> Now I'm not really sure how this is supposed to be fixed,
> 
> the gallium driver exports the formats it supports, which doesn't
> include the translated formats for PIPE_FORMAT_BGRA8888 and
> PIPE_FORMAT_8BGRX8888 which end up like PIPE_FORMAT_A8R8G8B8_UNORM
> this. This means no 8-bit visuals and ensuing fail.
> 
> Now I'm not sure the hw has any swappers or anything to facilitate
> these formats for rendering to, so it seems to me the pipe driver is
> doing the right thing, so my thinking is the state tracker should
> probably be dealing with this better, but again I'm not really sure
> how, maybe this just all worked in the past by luck.

I'm afraid it did.

> So should dri_fill_in_modes be doing a bit more on big endian? so if
> it can't find any formats the way it wants, it tries the other way,
> and reports those back so X gets different visuals with the masks all
> moved about?

Not sure we can do anything about the visuals, as X11 requires that all
the non-alpha bits are packed in the least significant bits in host byte
order.

This could probably still be solved in the state trackers though, by
falling back to formats which don't match the APIs they're providing,
and fixing things up as necessary when copying data to/from transfers.
Note that this would require adding explicit-endianness variants of many
formats, such as e.g. PIPE_FORMAT_*32*, where the components are now
defined in host byte order.


I'm attaching WIP patches for a different approach with r300g. The
second patch makes r300g advertise PIPE_FORMAT_*8R8G8B8_UNORM, but
treats them like PIPE_FORMAT_B8G8R8*8_UNORM for actual rendering
operations, and only converts to the API-specified formats for transfer
access. This mirrors what the Xorg radeon driver does to translate
between what X11 imposes and what the hardware supports. I assume
xf86-video-nouveau might be doing something similar.


-- 
Earthling Michel Dänzer            |                  http://www.amd.com
Libre software enthusiast          |                Mesa and X developer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-st-dri-Use-packed-RGB-formats.patch
Type: text/x-patch
Size: 3724 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131216/59106567/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-r300g-Big-endian-fixes.patch
Type: text/x-patch
Size: 14050 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131216/59106567/attachment-0003.bin>