Bug 72877 - Wrong colors with Mesa 9.2, 10.0, and 11.0.2 on PPC Linux systems
Summary: Wrong colors with Mesa 9.2, 10.0, and 11.0.2 on PPC Linux systems
Status: NEW
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r600 (show other bugs)
Version: 10.5
Hardware: PowerPC Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-19 11:25 UTC by Christian Zigotzky
Modified: 2016-02-25 19:06 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Lubuntu 13.10 PowerPC (Kernel 3.13-rc7) with the old Mesa 8.0.2 (620.60 KB, image/jpeg)
2014-01-06 21:06 UTC, Christian Zigotzky
Details
glxgears has wrong colors with Mesa 10.0.1 (503.37 KB, image/jpeg)
2014-01-06 22:39 UTC, Christian Zigotzky
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Zigotzky 2013-12-19 11:25:43 UTC
Hi all,

I've tried Mesa 9.2.2-1 and 10.0.0-1 on Debian Sid and Lubuntu 13.10. Unfortunately both have issued false colors in games. They appear to be ABGR instead of RGBA, thus blue becomes green, red becomes alpha etc.

Mesa 8.0.5-4 and Mesa 9.1.6 have no color problem.

The transitional solution is to install the old Mesa 8.0.X with "Force Version" with the Synaptic package manager on new distributions.

Hardware:

AmigaOne X1000 (Nemo)
PA Semi Dual-core PA6T-1682M, 1.8GHz PowerISA™ v2.04+ CPU
"Xena" 500MHz XMOS XS1-L2 124
8GB DDR2 SDRAM
HIS Radeon HD 6870, 1 GB RAM
OCZ600MXSP 600 Switching power supply
RTL 8139/8139C/8139C+ network card
TSSTcorp CDDVDW SH-224BB dvd drive
ATA ST2000DM001-9YN1 SEAGATE HD
ATA ESA 3SF1240GB HD

More information: 

http://en.wikipedia.org/wiki/AmigaOne_X1000
http://www.supertuxkart-amiga.de/amiga/x1000.html

Rgds,
Christian
Comment 1 Lauri Kasanen 2013-12-19 19:47:53 UTC
More specifically, this bug is about BGRA vertex colors, GL_EXT_vertex_array_bgra, seen in SuperTuxKart math level for example.
Comment 2 Michel Dänzer 2013-12-20 03:21:07 UTC
This is probably due to commit 2151d893fbd4a4be092098170e2fbca8c35797a5 ('gallium: Fix llvmpipe on big-endian machines'). The r600g driver needs to be adapted for the changed PIPE_FORMAT_* semantics.
Comment 3 Christian Zigotzky 2013-12-30 18:02:30 UTC
(In reply to comment #2)
> This is probably due to commit 2151d893fbd4a4be092098170e2fbca8c35797a5
> ('gallium: Fix llvmpipe on big-endian machines'). The r600g driver needs to
> be adapted for the changed PIPE_FORMAT_* semantics.

I don't know if I have correct understand your answer. Is the bug fixed?
Comment 4 Michel Dänzer 2014-01-06 09:18:43 UTC
(In reply to comment #3)
> Is the bug fixed?

Not yet. To fix it, the r600g driver needs to be adapted to changes in the way the Gallium3D infrastructure deals with big endian hosts.
Comment 5 Christian Zigotzky 2014-01-06 11:30:53 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Is the bug fixed?
> 
> Not yet. To fix it, the r600g driver needs to be adapted to changes in the
> way the Gallium3D infrastructure deals with big endian hosts.

Hi Michel,

Thanks a lot for your answer. :-) We had a problem with wrong colors in SuperTuxKart 0.8 last year. The Irrlicht guys have released a little hack for Irrlicht on Linux PPC (http://irrlicht.sourceforge.net/forum/viewtopic.php?f=7&t=48577). They told me that is a driver bug, and that workaround costs performance and RAM. Unfortunately this workaround isn't suitable for Mesa 9.2 and higher. At this time we have to install Mesa 9.1.X and lower on new Linux distributions like Lubuntu 13.10, Debian Sid etc. It would be nice to solve this issue because we don't need the workaround in the future.

All the best,

Christian
Comment 6 Christian Zigotzky 2014-01-06 21:06:42 UTC
Created attachment 91561 [details]
Lubuntu 13.10 PowerPC (Kernel 3.13-rc7) with the old Mesa 8.0.2

Lubuntu 13.10 PowerPC (Kernel 3.13-rc7) with the old Mesa 8.0.2. 3D acceleration works well in the fullscreen mode.
Comment 7 Christian Zigotzky 2014-01-06 22:39:08 UTC
Created attachment 91566 [details]
glxgears has wrong colors with Mesa 10.0.1
Comment 8 Christian Zigotzky 2014-02-02 12:07:35 UTC
Hi All,

I've installed Mesa 10.0.2 on Debian Sid PowerPC with the following commands:

apt-get install -t experimental libgl1-mesa-dri
apt-get install -t experimental libgl1-mesa-glx
apt-get install -t experimental mesa-utils
apt-get install -t experimental libdrm-radeon1
apt-get install -t experimental xserver-xorg-video-ati
apt-get install -t experimental xserver-xorg-video-radeon

glxinfo | grep OpenGL

OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD BARTS
OpenGL core profile version string: 3.1 (Core Profile) Mesa 10.0.2
OpenGL core profile shading language version string: 1.40
OpenGL core profile context flags: (none)
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.0.2
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

Unfortunately, the games have still wrong colors.

I've tested it with the kernel 3.11.0, 3.12.5, and 3.13.1.

Rgds,

Christian
Comment 9 Christian Zigotzky 2014-02-02 12:41:43 UTC
The problem is the package libgl1-mesa-dri. I have installed the old package libgl1-mesa-dri 8.0.5-4 with "Force Version" with the Synaptic package manager and this has solved the problem with the wrong colors.

-- Christian
Comment 10 Fabio Pedretti 2014-09-07 18:30:01 UTC
There are endianess patches here:
http://lists.freedesktop.org/archives/mesa-dev/2014-July/thread.html#63723

Still not applied. No idea if they properly fix this issue.
Comment 11 Fabio Pedretti 2014-09-17 11:42:18 UTC
Big-endian patches are in mesa git now. Is this still an issue?
Comment 12 Michel Dänzer 2014-09-17 14:45:29 UTC
(In reply to comment #11)
> Big-endian patches are in mesa git now. Is this still an issue?

Yes. The infrastructure changes are mostly complete now, but the hardware drivers still haven't been adapted to them.
Comment 13 Christian Zigotzky 2015-04-02 23:35:07 UTC
Is the r600g driver ready for the Gallium3D infrastructure of big endian hosts?
Comment 14 Alex Perez 2016-01-03 01:11:08 UTC
Ping. I am still experiencing problems with incorrect colors with the very latest Mesa, compiled from a fresh git checkout today.
Comment 15 Ilia Mirkin 2016-01-03 01:21:57 UTC
(In reply to Alex Perez from comment #14)
> Ping. I am still experiencing problems with incorrect colors with the very
> latest Mesa, compiled from a fresh git checkout today.

Mesa 11.0.3+ work fine on a PPC G5 with a NV34 GPU. Haven't tested much else. I don't think this is a "core" issue anymore.
Comment 16 joro-2013 2016-01-08 13:25:37 UTC
Allow me to add my experiences.

Whether the colors are garbled on PPC depends on the GL color format used (among probably a gazillion other parameters :-). Packed (16-bit) formats have been broken on big-endian for some time, they worked fine in mesa 10.1, in mesa 10.3 R5G5B5A1 works, R4G4B4A4 works with alpha glitches, somewhere in the 10.3 release cycle the format stuff got completely rewritten breaking pretty much all packed formats on big-endian (PPC).

Unpacked (32 bits) formats seem to be working fine.

That's on a RV280 32 bit system. No idea whether that is also valid for NV34 on 64-bit PPC, i.e. whether the problem is in core mesa or the radeon stuff.
Comment 17 joro-2013 2016-01-08 13:28:33 UTC
Addendum: Tested on the pcsx playstation emulator (which makes the GL format selectable) and the peopsxgl plugin ported to PPC.
Comment 18 Emil Velikov 2016-01-08 14:15:04 UTC
(In reply to joro-2013 from comment #16)
> Allow me to add my experiences.
> 
> Whether the colors are garbled on PPC depends on the GL color format used
> (among probably a gazillion other parameters :-). Packed (16-bit) formats
> have been broken on big-endian for some time, they worked fine in mesa 10.1,
> in mesa 10.3 R5G5B5A1 works, R4G4B4A4 works with alpha glitches, somewhere
> in the 10.3 release cycle the format stuff got completely rewritten breaking
> pretty much all packed formats on big-endian (PPC).
> 
> Unpacked (32 bits) formats seem to be working fine.
> 
> That's on a RV280 32 bit system. No idea whether that is also valid for NV34
> on 64-bit PPC, i.e. whether the problem is in core mesa or the radeon stuff.

The report in question is (was?) about the gallium radeon driver - r600g.

On the classic radeon/r200 front there was a regression caused by commit 779cabfc7d022de8b7b9bc7fdac0caffa8646c51 (which itself fixing some BE issues, circa 11.0), which was resolved in 11.0.6 and 11.1.0. If things are still off, then I'd suggest opening separate bug report and if possible bisecting it down.
Comment 19 joro-2013 2016-01-08 15:38:15 UTC
Actually i had already e-mailed Roland Scheideregger privately (thanking him for still giving some care to this ancient driver with BE systems although the commit didn't fix the problems :-).

I already tracked down the breakage that affects me to the (otherwise very sensible) pythonization of the format stuff around commit d4c780e052c9cc361bed5958b72b42d8151800c2 <quote>:


mesa: Add python to parse the formats CSV file
The basic concept for the format parser was taken from the format CSV
parser in gallium/auxilliary/util.  However, this one has been altered in a
number of ways:

 * Removed big endian vs. little endian stuff (mesa doesn't need it)
 * Better documentation: Almost every method has a full docstring
 * An actual Swizzle class with methods for composition and inverses
 * Over-all cleaner (in my opinion) implementation and class interactions 
 * A few bug fixes

</quote>

Ahhhh, the joys of optimized code-reuse :-)

Since i'm no pythonista i didn't want to wade into it and still use the 10.3 stuff. But maybe that's a hint for the r600g driver and this bug report.
Comment 20 Alex Perez 2016-01-20 18:03:56 UTC
Last night, I confirmed that the colors are *correct* with r300g on Big Endian (tested with an RV515), but still incorrect with r600g, as of Mesa 11.0.2. Therefore, I have changed the component for this bug from mesa core to r600.
Comment 21 Oded Gabbay 2016-02-25 07:24:13 UTC
Hi,
I posted two fixes for this to r600g driver (4b7e219 and 439b5b0).
I believe that with mesa master branch, the colors should now be mostly correct with 24-bit color.
Oded
Comment 22 Oded Gabbay 2016-02-25 19:06:49 UTC
So scrape that last comment.
The colors are correct when not using a compositor, because compositors (e.g. gnome-shell) get their info using textures, and the textures are still broken.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.