[Mesa-dev] gallium endianness and hw drivers

[Marek Olšák]

Some comments about the r300g patch.

The hardware doesn't support Axxx texture formats for blending and
alpha-test. Only xxxA formats are supported. The driver already
supports all formats it can support and no other formats can be added
(except for those where the component ordering matches
currently-advertised formats). Most importantly, the Axxx formats
shouldn't be advertised to the state tracker.

I think the hardware only has states for bit swapping. Other than
that, I'm afraid there's not much else we can do.

Marek

On Mon, Dec 16, 2013 at 10:15 AM, Michel Dänzer <michel at daenzer.net> wrote:
> 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
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>