[Mesa-dev] [PATCH] st/dri: Use packed RGB formats

[Ilia Mirkin]

On Mon, Sep 28, 2015 at 4:40 AM, Michel Dänzer <michel at daenzer.net> wrote:
> On 02.09.2015 01:49, Ilia Mirkin wrote:
>> On Mon, Aug 10, 2015 at 5:44 AM, Michel Dänzer <michel at daenzer.net> wrote:
>>>
>>> diff --git a/src/gallium/state_trackers/dri/dri_drawable.c b/src/gallium/state_trackers/dri/dri_drawable.c
>>> index 0d2929a..f0cc4a2 100644
>>> --- a/src/gallium/state_trackers/dri/dri_drawable.c
>>> +++ b/src/gallium/state_trackers/dri/dri_drawable.c
>>> @@ -231,11 +231,11 @@ dri_set_tex_buffer2(__DRIcontext *pDRICtx, GLint target,
>>>        if (format == __DRI_TEXTURE_FORMAT_RGB)  {
>>>           /* only need to cover the formats recognized by dri_fill_st_visual */
>>>           switch (internal_format) {
>>> -         case PIPE_FORMAT_B8G8R8A8_UNORM:
>>> -            internal_format = PIPE_FORMAT_B8G8R8X8_UNORM;
>>> +         case PIPE_FORMAT_BGRA8888_UNORM:
>>> +            internal_format = PIPE_FORMAT_BGRX8888_UNORM;
>>>              break;
>>> -         case PIPE_FORMAT_A8R8G8B8_UNORM:
>>> -            internal_format = PIPE_FORMAT_X8R8G8B8_UNORM;
>>> +         case PIPE_FORMAT_ARGB8888_UNORM:
>>> +            internal_format = PIPE_FORMAT_XRGB8888_UNORM;
>>>              break;
>>>           default:
>>>              break;
>>
>> This dri_drawable.c hunk is unnecessary.
>
> I guess you're right, thanks.
>
>
>> I wrote the same patch for dri2.c though. Any reason it didn't get
>> pushed?
>
> The immediate reason was that I remembered that this patch alone doesn't
> help for the r300g driver at least.
>
> Since then, it has occurred to me that this patch is actually wrong for
> r300g: The Xorg driver uses the same hardware formats on big and little
> endian hosts, it just swaps bytes on the CPU as necessary. This would
> correspond to using the same basic Gallium formats regardless of host
> byte order.
>
> OTOH with hardware supported by the r600g driver, the kernel and Xorg
> set up the hardware to always access data in host byte order, which
> corresponds to the approach in this patch.
>
> So, I'm afraid there's no simple solution in st/dri which works for both
> r300g and r600g. :(
>
>
> Which way do the nouveau kernel / Xorg drivers handle this?

Poorly :)

Unfortunately I don't have a clear idea in my head about how "BE" mode
works on NVIDIA hardware. I know it byte swaps the command stream,
which is extra fun when surface uploads go through the command stream.
But they can also be DMA'd in as well. However it might be smart about
what it byteswaps and what it leaves alone. I really don't know. I'm
also extremely interested in what happens with nv50+ hw, but my G5 is
AGP + PCI, no PCIe.

All I know is that it all worked fine in Mesa 9.1 but then has been
broken for quite a while, in varying states of disrepair (started out
with byteswapped colors, but has now moved on to no visuals being
reported).

I might just throw my hands up in the air and start reporting the BE
formats from nv30_format.c even though I'm moderately sure that's
wrong. This was Dave's approach although AFAIK he also hit unspecified
issues. I'm a lot more interested in having a driver that works than
one that reports formats correctly.

I have additional stability issues with the PPC G5 that I have, which
has made me procrastinate on doing additional debugging after solving
the (recent!) regression in the kernel module for BE. There's also a
(less-recent) regression that prevents nouveau from being loaded at
all via OF, which is also on my list.

  -ilia