Wouldn't it be easier to just revert the gallium endianness rework? If it breaks all hw drivers on big endian machines, it's apparently not done right.
Marek On Mon, Dec 16, 2013 at 8:05 AM, Dave Airlie <airl...@gmail.com> wrote: > So the llvmpipe endian work broke the nouveau nv40 support for the > nv43 in the ppc G5 a few people have, > > 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. > > 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? > > Dave. > _______________________________________________ > 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
