On Mon, Sep 28, 2015 at 4:40 AM, Michel Dänzer <[email protected]> wrote: > On 02.09.2015 01:49, Ilia Mirkin wrote: >> On Mon, Aug 10, 2015 at 5:44 AM, Michel Dänzer <[email protected]> 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 _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
