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 <mic...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev