[PPC] Wrong colours on big-endian machine

[Marcus Comstedt]

After upgrading to Jaunty, colours are wrong in GL applications.

I did a testprogram which is supposed to show a red square, a green square,
a blue square and a white square on a black background. What I get is
a cyan square, a purple square, a blue square, and a white square on a
blue background. (See screenshot, where I also have glxgears running.)

So, red and green are swapped, and blue is always set (which probably
means that it is swapped with alpha). Which sounds like byteorder
problems.

The problem is the same regardless of LIBGL_ALWAYS_INDIRECT setting,
so I'm guessing it is a bug in the GLX layer rather than in the actual
renderer.

libgl1-mesa-glx version: 7.4-0ubuntu3

Hardware: Mac Mini (PPC), Radeon 9200

[Andrey Gusev (ronne-list)]

I have same bug on debian pps.
Hardware: PowerMac3,6, nvidia GeForce4 MX 420.
OpenGL version string: 2.1 Mesa 7.4.1

[Marcus Comstedt (marcus-mc)]

After upgrading to karmic, the same problem remains.

[Marcus Comstedt (marcus-mc)]

In current Lucid (with mesa 7.7). the problem seems to be fixed (tested with today's live CD snapshot).

[Andrey Gusev (ronne-list)]

Which did you use render engine? There are 2 upstream bugs: http://bugs.freedesktop.org/show_bug.cgi?id=22767 and http://bugs.freedesktop.org/show_bug.cgi?id=22017 First was fixed, but second isn't resolved. May be it is fixed too.

[Marcus Comstedt (marcus-mc)]

I was running without LIBGL_ALWAYS_SOFTWARE, dmesg showed that radeon drm was loaded, and glxinfo showed "direct rendering: Yes". I suppose that means I was using the radeon render engine, but if there is a better way to know for sure, please let me know... :-)

[Andrey Gusev (ronne-list)]

glxgears -info
See GL_RENDERER string. if it isn't 'Software Rasterizer', then hardware rendering is enabled.

[Marcus Comstedt (marcus-mc)]

glxgears -info =>
GL_RENDERER = Software Rasterizer

Xorg.log says:

(II) RADEON(0): RADEONInitMemoryMap() :
(II) RADEON(0): mem_size : 0x04000000
(II) RADEON(0): MC_FB_LOCATION : 0x9bff9800
(II) RADEON(0): MC_AGP_LOCATION : 0xffffffc0
(II) RADEON(0): Depth moves disabled by default
(II) RADEON(0): Using 8 MB GART aperture
(II) RADEON(0): Using 1 MB for the ring buffer
(II) RADEON(0): Using 2 MB for vertex/indirect buffers
(II) RADEON(0): Using 5 MB for GART textures
(II) RADEON(0): Memory manager initialized to (0,0) (2048,4096)
(II) RADEON(0): Reserved area from (0,2048) to (2048,2050)
(II) RADEON(0): Largest offscreen area available: 2048 x 2046
(II) RADEON(0): Will use front buffer at offset 0x0
(II) RADEON(0): Will use back buffer at offset 0x0
(II) RADEON(0): Will use depth buffer at offset 0x1000000
(II) RADEON(0): Will use 0 kb for textures at offset 0x2000000
(EE) RADEON(0): Static buffer allocation failed. Disabling DRI.
(EE) RADEON(0): At least 49152 kB of video memory needed at this resolution and
depth.
(II) RADEON(0): RADEONRestoreMemMapRegisters() :
(II) RADEON(0): MC_FB_LOCATION : 0x9bff9800 0x7fff0000
(II) RADEON(0): MC_AGP_LOCATION : 0xffffffc0
(==) RADEON(0): Backing store disabled
(WW) RADEON(0): Direct rendering disabled

Hm?

[Marcus Comstedt (marcus-mc)]

Ah-ha! After some googling, I found that with newer Xorg, you need to define
a Virtual attribute for each Display subsection in xorg.conf, or you will not get
HW rendering. (Is there already a launchpad issue for this?)
The live CD does not come with any xorg.conf at all, so of course no
direct rendering. After installing an xorg.conf with the required Virtual
attributes, I get

GL_RENDERER = Mesa DRI R200 (RV280 5962) 20090101 AGP 4x PowerPC/Altivec TCL

(and 700 fps instead of 100), and color is still ok.

[Marcus Comstedt (marcus-mc)]

But wait, it gets better! It turns out that karmic also has the bug with xorg.conf.

After adding the kluge to my xorg.conf, it turns out that HW rendering actually
gets the colors right in karmic too, only SW rendering is wrong in karmic.

[Andrey Gusev (ronne-list)]

Software rendering was fixed in mesa 7.6.1. Karmic has mesa 7.6.0. So since 7.6.1 all should be good everywhere.

[Bryce Harrington (bryce)]

Hi Marcus,

        Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with the latest development release of Ubuntu? (ISO CD images are available from http://cdimage.ubuntu.com/releases/)

        If it remains an issue, could you also attach a new /var/log/Xorg.0.log?
        Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[Marcus Comstedt (marcus-mc)]

Hi.

As already stated (in comment #6), the problem is fixed in lucid. Since I have upgraded to lucid,
this is no longer an issue for me.

[Vish (vish)]

Thanks for following up. This bug report is being closed due to your last comment regarding this being resolved. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.