Bug 22017

Summary: Incorrect Colours Radeon 9200 - Mesa 7.4-1
Product: Mesa Reporter: Tom Medhurst <tom.medhurst>
Component: Drivers/DRI/r200Assignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: phil, pxwpxw8, ronne
Version: unspecified   
Hardware: PowerPC   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: xorg.conf
glxgears screenshot

Description Tom Medhurst 2009-06-01 01:56:17 UTC
Created attachment 26331 [details]
xorg.conf

When running glxgears (or any of my own opengl programs) the colors are incorrect.
White is yellow, red is green etc..
X11 is fine and colors are spot on.

I am running a MacMini PowerPC 1.24GHz with 512 RAM (ATI Radeon 9200) with ArchLinux-ppc.
I have Mesa 7.4-1 and libgl 7.4-1 installed from the extra repository (not from source).

Attached is a screenshot of glxgears and my xorg.conf file.
Many Thanks in advance
tommed
Comment 1 Tom Medhurst 2009-06-01 01:57:35 UTC
Created attachment 26332 [details]
glxgears screenshot
Comment 2 Michel Dänzer 2009-06-02 01:40:37 UTC
Does it also happen with upstream Git mesa_7_4_branch? This used to work, and if there was a regression I'm surprised it wasn't reported earlier...
Comment 3 Phil Armstrong 2009-06-06 14:23:00 UTC
It certainly happens with mesa git HEAD (as of 20090606, commit f1edfa09ea50e8833ddbf241da4d36fd38685e9d). I haven't tried the 7.4 branch.

It's been the case for ages that mesa renders colours incorrectly on radeon cards on powerpc platforms: it happens both on the G4 laptop & G4 mac mini I have.

Sorry I never got around to reporting it: turning on dri locks up my laptop & I only just acquired the mac mini which confirmed the bug.
Comment 4 Phil Armstrong 2009-06-06 14:32:46 UTC
NB Mesa 7.0.3 gets the colours correct.
Comment 5 Phil Armstrong 2009-06-06 14:37:26 UTC
(In reply to comment #4)
> NB Mesa 7.0.3 gets the colours correct.

The software renderer for mesa git head (seting LIBGL_ALWAYS_SOFTWARE=1) gets the colours wrong as well.
Comment 6 Phil Armstrong 2009-06-06 14:39:01 UTC
I can probably git bisect between the 7 release and 7.4 to see where the bug was introduced. Might take a while though.
Comment 7 Phil Armstrong 2009-06-06 15:17:10 UTC
(In reply to comment #6)
> I can probably git bisect between the 7 release and 7.4 to see where the bug
> was introduced. Might take a while though.

Ugh. There's something weird going on: A stock Debian Lenny install had the correct colours for glxgears, but I've dragged in a bunch of stuff from unstable so I could use the latest radeon driver & now even the stock Lenny mesa (mesa 7.0.3 / libdrm 2.3.1) gets the colours messed up. I'll see if I can downgrade everything to confirm the above.
Comment 8 Phil Armstrong 2009-06-06 15:50:25 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > I can probably git bisect between the 7 release and 7.4 to see where the bug
> > was introduced. Might take a while though.
> 
> Ugh. There's something weird going on: A stock Debian Lenny install had the
> correct colours for glxgears, but I've dragged in a bunch of stuff from
> unstable so I could use the latest radeon driver & now even the stock Lenny
> mesa (mesa 7.0.3 / libdrm 2.3.1) gets the colours messed up. I'll see if I can
> downgrade everything to confirm the above.
> 

OK. Mesa git HEAD works just fine with xorg version 7.3 (with libdrm 2.4.9) which probably explains why this bug hasn't been reported before.

Guess: the latest radeon driver in Xorg release 7.4 is setting a register (byte ordering?) somewhere that mesa doesn't know about, or has assumed is set to something else.

bisecting the radeon driver may be tricky though: IIRC it has a dependency on the new X server.
Comment 9 Michel Dänzer 2009-06-08 06:59:59 UTC
(In reply to comment #8)
> bisecting the radeon driver may be tricky though: IIRC it has a dependency on
> the new X server.

There should only be an ABI dependency between binaries, no source level dependency. What are the good/bad versions of xf86-video-ati?

(In reply to comment #5)
> The software renderer for mesa git head (seting LIBGL_ALWAYS_SOFTWARE=1) gets
> the colours wrong as well.

That's a separate issue which would need to be tracked separately.

(In reply to comment #3)
> It's been the case for ages that mesa renders colours incorrectly on radeon
> cards on powerpc platforms: it happens both on the G4 laptop & G4 mac mini I
> have.
> 
> Sorry I never got around to reporting it: turning on dri locks up my laptop & I
> only just acquired the mac mini which confirmed the bug.

I've been using 3D hardware acceleration (with correct colours ;) on various PowerMacs for almost a decade, and fixing bugs as I was aware of them. It's hard to fix bugs you don't know about...
Comment 10 Phil Armstrong 2009-06-08 07:25:18 UTC
>I've been using 3D hardware acceleration (with correct colours ;) on various
>PowerMacs for almost a decade, and fixing bugs as I was aware of them. It's
>hard to fix bugs you don't know about...

I appreciate that!

I'll try and nail down the problematic release. Assuming there's not some weird heisenbug thing going on of course. It seems to work fine with Xorg 1.4 series releases at least, which suggests a change in the 1.4->1.6 transition. Will confirm later.
Comment 11 Brian DeRocher 2009-07-13 11:20:20 UTC
I see this issue with Blender and glxgears.  Everything is blue / purple.

I'm on a PowerPC G5 with a Radeon card with Debian unstable.

brian@three:~$ uname -a
Linux three 2.6.30-1-powerpc64 #1 SMP Sun Jun 14 12:48:04 CEST 2009 ppc64 GNU/Linux

brian@three:~$ lspci -v 
<snip>
0000:f0:10.0 VGA compatible controller: ATI Technologies Inc RV350 AP [Radeon 9600] (prog-if 00 [VGA controller])
        Subsystem: ATI Technologies Inc RV350 AP [Radeon 9600]
        Flags: bus master, 66MHz, medium devsel, latency 16, IRQ 48
        Memory at a0000000 (32-bit, prefetchable) [size=256M]
        I/O ports at 0400 [size=256]
        Memory at 90000000 (32-bit, non-prefetchable) [size=64K]
        Expansion ROM at 90020000 [disabled] [size=128K]
        Capabilities: <access denied>
        Kernel driver in use: radeonfb

Here are my package versions:

ii  libgl1-mesa-dev    7.4.1-1 A free implementation of the OpenGL API -- G
ii  libgl1-mesa-dri    7.4.1-1 A free implementation of the OpenGL API -- D
ii  libgl1-mesa-glx    7.4.1-1 A free implementation of the OpenGL API -- G
ii  libglu1-mesa       7.4.1-1 The OpenGL utility library (GLU)
ii  libglu1-mesa-dev   7.4.1-1 The OpenGL utility library -- development fi
ii  mesa-common-dev    7.4.1-1 Developer documentation for Mesa
ii  mesa-utils         7.4.1-1 Miscellaneous Mesa GL utilities

ii  xserver-xorg                1:7.4+3        the X.Org X server
ii  xserver-xorg-core           2:1.6.1.901-3  Xorg X server - core server
ii  xserver-xorg-video-radeon   1:6.12.2-2     X.Org X server -- ATI Radeon display driver

ii  xserver-xorg-video-radeon   1:6.12.2-2     X.Org X server -- ATI Radeon display driver

Let me know if i can help.
Comment 12 Michel Dänzer 2009-07-13 11:32:07 UTC
(In reply to comment #11)
> 0000:f0:10.0 VGA compatible controller: ATI Technologies Inc RV350 AP [Radeon
> 9600] (prog-if 00 [VGA controller])

Huh - I haven't seen this problem on my PowerBook, which also has an RV350.

Can you reproduce the problem with upstream builds of xf86-video-ati and mesa?
Comment 13 Cros 2009-07-14 00:14:25 UTC
I see the same incorrect color for glxgears with nvidia graphics on G5 powerpc. Same result as on iBookg4 with Radeon 9200.

G5 -

0000:f0:10.0 VGA compatible controller [0300]: nVidia Corporation NV34 
[GeForce FX 5200 Ultra] [10de:0321] (rev a1)

/etc/X11/xorg.conf - 	Driver "nouveau"

ii  xserver-xorg-video-nouveau    1:0.0.10~git+20090404+11be9a9-0ubuntu1 

Linux g5 2.6.28-6-powerpc64-smp #18-Ubuntu SMP Wed Apr 8 09:33:39 UTC 2009 ppc64 GNU/Linux
Comment 14 Michel Dänzer 2009-07-14 02:43:23 UTC
(In reply to comment #13)
> I see the same incorrect color for glxgears with nvidia graphics on G5 powerpc.

See comment #9 about LIBGL_ALWAYS_SOFTWARE=1. That's a bug in the Mesa swrast DRI driver that would need to be tracked separately.
Comment 15 Andrey Gusev 2009-07-14 11:55:28 UTC
I have same problem on powermac g4. It is reproduces on nv and nouveau drivers. Also LIBGL_ALWAYS_INDIRECT=1 doesn't change anything.

Kernel: Linux 2.6.30.1 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libgl1-mesa-glx depends on:
ii  libc6                         2.9-12     GNU C Library: Shared libraries
ii  libdrm2                       2.4.11-1   Userspace interface to kernel DRM 
ii  libx11-6                      2:1.2.1-1  X11 client-side library
ii  libxdamage1                   1:1.1.1-4  X11 damaged region extension libra
ii  libxext6                      2:1.0.4-1  X11 miscellaneous extension librar
ii  libxfixes3                    1:4.0.3-2  X11 miscellaneous 'fixes' extensio
ii  libxxf86vm1                   1:1.0.2-1  X11 XFree86 video mode extension l

Versions of packages libgl1-mesa-glx recommends:
ii  libgl1-mesa-dri               7.4.4-1    A free implementation of the OpenG

0000:00:10.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 MX 420] (rev a3) (prog-if 00 [VGA controller])
	Subsystem: nVidia Corporation Device 0008
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 248 (1250ns min, 250ns max)
	Interrupt: pin A routed to IRQ 48
	Region 0: Memory at 91000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: Memory at 98000000 (32-bit, prefetchable) [size=128M]
	Region 2: Memory at f1000000 (32-bit, prefetchable) [size=512K]
	Expansion ROM at 90000000 [disabled] [size=128K]
	Capabilities: [60] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [44] AGP version 2.0
		Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA- ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
		Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>

andrey@power-debian:~$ glxinfo 
name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
    GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method, 
    GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, 
    GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, 
    GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, 
    GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, 
    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, 
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
    GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
GLX version: 1.2
GLX extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method, 
    GLX_SGIS_multisample, GLX_SGIX_fbconfig
OpenGL vendor string: Mesa Project
OpenGL renderer string: Software Rasterizer
OpenGL version string: 2.1 Mesa 7.4.4
OpenGL shading language version string: 1.20
Comment 16 Andrey Gusev 2009-07-14 12:27:18 UTC
I created bug for software rendering https://bugs.freedesktop.org/show_bug.cgi?id=22767
Comment 17 Andrey Gusev 2010-02-19 11:20:22 UTC
According to testing in Ubuntu karmic , this bug was fixed at least in mesa 7.6.0. https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/366755

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.