More specifically, this bug is about BGRA vertex colors, GL_EXT_vertex_array_bgra, seen in SuperTuxKart math level for example.

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.

(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?

(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.

(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

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.

Created attachment 91566 [details]
glxgears has wrong colors with Mesa 10.0.1

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

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

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.

Big-endian patches are in mesa git now. Is this still an issue?

(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.

Is the r600g driver ready for the Gallium3D infrastructure of big endian hosts?

Ping. I am still experiencing problems with incorrect colors with the very latest Mesa, compiled from a fresh git checkout today.

(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.

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.

Addendum: Tested on the pcsx playstation emulator (which makes the GL format selectable) and the peopsxgl plugin ported to PPC.

(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.

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.

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.

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

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.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/477.