Created attachment 127816 [details] WebGL coloring glitch. Running some OpenGL programs on PowerMac G5 with NVIDIA GeForce 6600LE shows problematic rendering: - Wrong coloring, simply looks like inverts or blue/purple hue (WebGL demo, Plasma Discover, Compiz, Linthesia, etc.) - Text disappears (in the case of Plasma Discover). - Flickering and glitchy flashing texture in general (in the case of Linthesia). This problem could be reproduced with Mesa 12.0.3 and 13.0.0 (which relates with another issue I have just reported in this section https://bugs.freedesktop.org/show_bug.cgi?id=98629). Any how, some screenshots are provided below to demonstrate my issue.
Created attachment 127817 [details] Linthesia (title screen), showing bad coloring.
Created attachment 127818 [details] Linthesia (playback view), showing wrong color and glitches.
Created attachment 127819 [details] Plasma Discover, showing bad coloring and disappearing text.
Probably RGB vs BGR confusion. Can you create an apitrace of the problem? I'll need to give this a whirl on my G5 (hm, if I can - I have a GeForce FX 5200 in mine). I should try to track down a PCI nv4x that I can plug in.
(In reply to Ilia Mirkin from comment #4) > Probably RGB vs BGR confusion. Can you create an apitrace of the problem? > I'll need to give this a whirl on my G5 ... Is it an application related issue then? The specific line where Linthesia maps its textures onto GL could be found here: https://github.com/linthesia/linthesia/blob/master/src/Tga.cpp#L217 I tried changing it from RGBA to BGRA today, which did change the color output, but still in incorrect colors like yellow and brown (or maybe I have completely butchered my RGB translation "knowledge"). > ... (hm, if I can - I have a GeForce FX 5200 in mine). I should try to track > down a PCI nv4x that I can plug in. Is it a Quad? I believe they are pretty cheap these days...
Indeed, after removing nouveau_dri.so, the Plasma Discover at least renders the full interface now. However, it still shows bad coloring. Screenshot attached.
Created attachment 127821 [details] Plasma Discover after nouveau_dri.so was removed.
(In reply to Mingcong Bai from comment #5) > (In reply to Ilia Mirkin from comment #4) > > Probably RGB vs BGR confusion. Can you create an apitrace of the problem? > > I'll need to give this a whirl on my G5 ... > > Is it an application related issue then? Nope. Just the trickiness of dealing with a BE cpu and a LE-but-kinda-BE-sometimes GPU. Unfortunately I don't have a clear model in my head of precisely what all the "BE" flag flips on these GPUs, which makes things much trickier. > > ... (hm, if I can - I have a GeForce FX 5200 in mine). I should try to track > > down a PCI nv4x that I can plug in. > > Is it a Quad? I believe they are pretty cheap these days... It's a PowerMac7,2 IIRC. It has an AGP slot (with the FX 5200) and some number of PCI slots. I glanced at nv4x boards, but they're above my tolerance of things I buy for the purpose of developing free drivers in my own time. (In reply to Mingcong Bai from comment #6) > Indeed, after removing nouveau_dri.so, the Plasma Discover at least renders > the full interface now. > > However, it still shows bad coloring. Oh interesting. That means the confusion is in the DDX. (Or disagreement between mesa and the DDX.) Please confirm that you're running a semi-recent version of xf86-video-nouveau (e.g. 1.0.12), and actually verify that it says NOUVEAU(0) in your xorg log.
> Oh interesting. That means the confusion is in the DDX. (Or disagreement > between mesa and the DDX.) Please confirm that you're running a semi-recent > version of xf86-video-nouveau (e.g. 1.0.12), and actually verify that it > says NOUVEAU(0) in your xorg log. Definitely... [ 18082.072] (II) AIGLX: Suspending AIGLX clients for VT switch [ 18082.072] (II) NOUVEAU(0): NVLeaveVT is called. [ 18609.555] (II) AIGLX: Resuming AIGLX clients after VT switch [ 18609.555] (II) NOUVEAU(0): NVEnterVT is called. [ 18609.588] (II) NOUVEAU(0): EDID vendor "DEL", prod id 41112 [ 18609.588] (II) NOUVEAU(0): Using hsync ranges from config file [ 18609.588] (II) NOUVEAU(0): Using vrefresh ranges from config file [ 18609.588] (II) NOUVEAU(0): Printing DDC gathered Modelines: And yes, it should be the newest version available: jeffbai@G5-AOSC [ ~ ] $ dpkg -s xf86-video-nouveau Package: xf86-video-nouveau Status: install ok installed Section: x11 Installed-Size: 364 Maintainer: Everette Rong <l.e.r@riseup.net> Architecture: ppc64 Version: 1.0.12 Depends: xorg-server (>= 1.18.4), libdrm (>= 2.4.70), systemd (>= 1:231-2) Description: XF86 driver for NVIDIA graphics cards
And which driver ends up being active in this mode (where nouveau_dri is gone)? (glxinfo | grep renderer should have the relevant info)
> And which driver ends up being active in this mode (where nouveau_dri is gone)? > (glxinfo | grep renderer should have the relevant info) LLVMpipe.
Could you try booting with nouveau.config=NvPCIE=0 and seeing if this has any effect on any of your issues?
(In reply to Ilia Mirkin from comment #12) > Could you try booting with nouveau.config=NvPCIE=0 and seeing if this has > any effect on any of your issues? Nope, the situation is identical. I have attached some screenshots for you.
Created attachment 127825 [details] KDE, wrong color 1 Note that systemsettings shows the right color in this case.
Created attachment 127826 [details] KDE wrong color 2
(In reply to Mingcong Bai from comment #13) > (In reply to Ilia Mirkin from comment #12) > > Could you try booting with nouveau.config=NvPCIE=0 and seeing if this has > > any effect on any of your issues? > > Nope, the situation is identical. I have attached some screenshots for you. Also I have tried to use "fbdev" driver for Xorg, which results in the same bad color display. Maybe this issue is not here at nouveau? Either down in Mesa or up at Qt?
Suspecting that this could still be an application-based issue, I have filed some issues to GNOME and KDE developers, as their desktop environment have the same coloring issue while XFCE and MATE worked just fine: - https://bugs.kde.org/show_bug.cgi?id=372202 - https://bugzilla.gnome.org/show_bug.cgi?id=774085
(In reply to Mingcong Bai from comment #17) > Suspecting that this could still be an application-based issue, I have filed > some issues to GNOME and KDE developers, as their desktop environment have > the same coloring issue while XFCE and MATE worked just fine: > > - https://bugs.kde.org/show_bug.cgi?id=372202 > - https://bugzilla.gnome.org/show_bug.cgi?id=774085 Could you confirm that nouveau.nomodeset=1 (+ fbdev) produces these bad effects as well? Should be able to use offb assuming that OF knows how to deal with your GPU.
(In reply to Ilia Mirkin from comment #18) > (In reply to Mingcong Bai from comment #17) > > Suspecting that this could still be an application-based issue, I have filed > > some issues to GNOME and KDE developers, as their desktop environment have > > the same coloring issue while XFCE and MATE worked just fine: > > > > - https://bugs.kde.org/show_bug.cgi?id=372202 > > - https://bugzilla.gnome.org/show_bug.cgi?id=774085 > > Could you confirm that nouveau.nomodeset=1 (+ fbdev) produces these bad > effects as well? Should be able to use offb assuming that OF knows how to > deal with your GPU. Er, sorry - that should have been "nomodeset" bare in the kernel cmdline. Or "nouveau.modeset=0". I think.
Created attachment 127847 [details] Fbdev and nomodeset And... This happened (my eyes).
-- 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/1116.
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.