[Mesa-dev] [PATCH 2/2] mesa: _mesa_format_convert should be endian agnostic

Christian Zigotzky chzigotzky at xenosoft.de
Tue Aug 4 00:23:23 PDT 2015

Hi All,

I know the false colors problems. Some Linux programs appear to be ABGR 
instead of RGBA, thus green becomes purple, red becomes light blue etc.

I created a bug report on freedesktop.org. Bug report 72877: 
https://bugs.freedesktop.org/show_bug.cgi?id=72877 and 

I also created a bug report on bugs.launchpad.net. Bug report #1275042: 

Additionally I posted the bug on the Mesa dev mailing list: 

I also posted it in the ubuntuforums' PPC forum: 
http://ubuntuforums.org/showthread.php?t=2214923 and I posted it on the 
Debian PPC mailing list: 

I figured out what the problem is and I have fixed the problem in the 
MesaLib source code. I released some unofficial Mesa packages. 
Downloads: http://www.supertuxkart-amiga.de/amiga/mesalib-unofficial.html.

I fixed the wrong colors issues in SuperTuxKart. Downloads: 
http://www.supertuxkart-amiga.de/amiga/x1000.html#downloads. But I know, 
it affects a lot of other programs.

Furthermore I posted some information about this problem in the 
following thread: 

There is a second problem with all Radeon HD 7XXX and higher. 3D for 
these requires LLVM to compile the shaders. We compiled the new Mesa 
versions with LLVM, but there was a bug in LLVM that meant it wouldn't 
work on PPC.

At the time we are still using the unofficial Mesa versions for our NG 
Amigas and Power Macs. Unfortunately these work only with Radeon HD 6XXX 
and lower.



On 03 August 2015 5:40 PM, Emil Velikov wrote:
> Hi Oded,
> On 2 August 2015 at 11:37, Oded Gabbay <oded.gabbay at gmail.com> wrote:
>> This patch fixes a bug that is manifested in the read path of mesa when
>> running on big-endian machines. The effects can be seen when running
>> piglit sanity test and/or taking a screen capture.
>> The bug is caused when _mesa_format_convert receives src_format as
>> mesa_format, which it thens changes to mesa_array_format. During this
>> change, it checks for endianness and swaps the bytes accordingly.
>> However, because the bytes are _already_ swapped in the memory itself
>> (being written there by llvmpipe), and src_format value matches the
>> _actual_ contents of the memory, the result of the read is wrong.
> I'm assuming that you're looked at swrast + softpipe as well - do they
> use the same approach or is llvmpipe the odd one out ?
> Curious if your work has any effect on the big endian + r600 issue
> [1]. I believe Christian Zigotzky (Cc'ed) was very passionate about
> getting his r600 working - perhaps he can give your patches a test ?
> ... just to make sure that things don't go even worse :)
> Cheers,
> Emil
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=72877

More information about the mesa-dev mailing list