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
Created attachment 26332 [details] glxgears screenshot
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...
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.
NB Mesa 7.0.3 gets the colours correct.
(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.
I can probably git bisect between the 7 release and 7.4 to see where the bug was introduced. Might take a while though.
(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.
(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.
(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...
>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.
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.
(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?
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
(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.
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
I created bug for software rendering https://bugs.freedesktop.org/show_bug.cgi?id=22767
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.