Ubuntu 11.04, Linux 3.0.1, Mesa 7.12-devel and R600g from xorg-edgers PPA (version of Mesa and R600g is git20110801). Screenshot of BEEP game attached (distribution from Gameolith.com). Same problem also reproduced in Source-based games under WINE, but not reproduced for example in Unigine Heaven and OilRush.
Is this a regression? Please attach your xorg log, dmesg output, and glxinfo output.
Created attachment 50014 [details] [review] Xorg log
Created attachment 50015 [details] dmesg output
Created attachment 50016 [details] glxinfo output
> Is this a regression? I don't know. I first time try R600g in this year. In previous year I didn't run games with R600g. > Please attach your xorg log, dmesg output, and glxinfo output. Attached. I also want to note: BEEP and WINE are x86. Unigine Heaven and OilRush are x86_64. So maybe it's somehow related to the problem. I also try to launch StarCraft II under WINE (x86). Same problem on splashscreen and also GPU lockup: https://bugs.freedesktop.org/show_bug.cgi?id=39902
I don't see any screenshot, did you forget to attach it? The games you mention (BEEP, Source titles) have been working fine here.
32 bit games require a 32 bit 3D driver, so make sure you also updated your 32 bit driver.
Created attachment 50020 [details] BEEP screenshot
> I don't see any screenshot, did you forget to attach it? Yes, sorry. Attached. > 32 bit games require a 32 bit 3D driver, so make sure you also updated your 32 bit driver. Ok, I will check.
*** Bug 39877 has been marked as a duplicate of this bug. ***
@Alex Deucher I didn't reply before to let you enjoy your week-end. But you were right, to fix this issue create or update a xorg.conf with the following content : Section "Device" Identifier "Configured Video Device" Option "ColorTiling" "False" EndSection I have two questions though - "32 bit games require a 32 bit 3D driver" : how do we check that ? LIBGL_DEBUG=verbose glxinfo ? In my case, it opens r600_dri.so from a x86_64 folder. I tried to find a guide or a FAQ (as it seems a fairly common issue) in vain. - Is there a "proper" fix ? Do you want us to test something ? to apply a patch ? We'd be glad to do the "boring" thing (compiling+testing).
> 32 bit games require a 32 bit 3D driver, so make sure you also updated your 32 bit driver. This bug is not reproduced for me on pure x86 setup of Ubuntu Oneiric with and without xorg-edgers PPA updates. So I think it's a packaging problem of Oneiric/xorg-edgers Mesa or drivers packages. But I didn't know what exactly broken to file proper bugreport to Canonical. How can I check what's broken in packages for Oneiric/xorg-edgers?
(In reply to comment #11) > I have two questions though > - "32 bit games require a 32 bit 3D driver" : how do we check that ? > LIBGL_DEBUG=verbose glxinfo ? > In my case, it opens r600_dri.so from a x86_64 folder. That's because glxinfo is 64-bit. You need to set the environment variable when you launch a 32-bit app, like BEEP. > I tried to find a guide or a FAQ (as it seems a fairly common issue) in vain. > - Is there a "proper" fix ? Do you want us to test something ? to apply a patch > ? We'd be glad to do the "boring" thing (compiling+testing). This is really more of a distro problem. (Personally I see no real reason to bother with 64-bit if you have any interest to run proprietary games and stuff using Wine. Hopefully this will be less of an issue once Debian and Ubuntu makes the transition to proper multi-arch.)
alex@Leon:~/Projects/Games/CrayonPhysicsDeluxe$ LIBGL_DEBUG=verbose ./launcher <snip> libGL: OpenDriver: trying /usr/lib/dri/tls/r600_dri.so libGL: OpenDriver: trying /usr/lib/dri/r600_dri.so libGL error: dlopen /usr/lib/dri/r600_dri.so failed (/usr/lib/dri/r600_dri.so: cannot open shared object file: No such file or directory) libGL: OpenDriver: trying /usr/lib/dri-alternates/tls/r600_dri.so libGL: OpenDriver: trying /usr/lib/dri-alternates/r600_dri.so libGL error: dlopen /usr/lib/dri-alternates/r600_dri.so failed (/usr/lib/dri-alternates/r600_dri.so: cannot open shared object file: No such file or directory) libGL: OpenDriver: trying /usr/lib32/dri/tls/r600_dri.so libGL: OpenDriver: trying /usr/lib32/dri/r600_dri.so <snip> alex@Leon:~$ find / -name "r600_dri.so" 2> /dev/null /usr/lib32/dri-alternates/r600_dri.so /usr/lib32/dri/r600_dri.so /usr/lib/x86_64-linux-gnu/dri/r600_dri.so alex@Leon:~$ file /usr/lib32/dri/r600_dri.so /usr/lib32/dri-alternates/r600_dri.so /usr/lib32/dri/r600_dri.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped /usr/lib32/dri-alternates/r600_dri.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped alex@Leon:~$ md5sum /usr/lib32/dri-alternates/r600_dri.so /usr/lib32/dri/r600_dri.so a8b52ca9129e3cc2902f9a9473866972 /usr/lib32/dri-alternates/r600_dri.so fdef193b5e49473c741f3dbfad0c4737 /usr/lib32/dri/r600_dri.so alex@Leon:~$ dpkg -S /usr/lib32/dri/r600_dri.so /usr/lib32/dri-alternates/r600_dri.so ia32-libs: /usr/lib32/dri/r600_dri.so ia32-libs: /usr/lib32/dri-alternates/r600_dri.so alex@Leon:~$ sudo apt-cache show ia32-libs Package: ia32-libs Priority: optional Section: universe/libs Installed-Size: 193896 Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> Original-Maintainer: Debian ia32-libs Team <pkg-ia32-libs-maintainers@lists.alioth.debian.org> Architecture: amd64 Version: 20090808ubuntu13 Filename: pool/universe/i/ia32-libs/ia32-libs_20090808ubuntu13_amd64.deb Origin: Ubuntu So that's where the issue come from : a very old ia32-libs package. But on the xorg-edgers home page, there is the following message : == New in the PPA - 2011/06/30 == Multiarch xserver/mesa is in the process of being uploaded to natty and oneiric, this transition will take some time to work out and it's advised not to use the PPA if you are using proprietary drivers. Should I fill a bug anyway ?
Forgot to say I filed a bug asking to build ia32-libs in xorg-edgers PPA (as done for lucid and maverick) : --> https://bugs.launchpad.net/xorg-server/+bug/824346
Created attachment 51591 [details] xonotic 1600x900, glsl enabled I have seen the same behaviour in some 3d programs and I also have to add some information. mobile HD 6550 = HD 5650 xorg 1.10 and later 1.11, did not make a difference mesa git libdrm git xf86-video-ati git - The corruption consistently only happens in certain window width/heights. 1600x900 seem to always be bad, while on 1152x768 it works well. - Deactivating compositing has no effect. - It happens in 32 bit wine programs as well as in 64 bit programs on a 64 bit Archlinux (I don't get what that ubuntu discussion is about) I have seen this in: - xonotic 0.5 with GLSL enabled. Without GLSL it renders (mostly) fine on 1600x900. So I suspect the problem there. - Portal 2 in wine. But strangely Half Life 2 Episode 1 worked well. - Trackmania Nations in wine - An Ubuntu 11.10 beta VM in Virtualbox with the guest additions enabled - mplayer with g3dvl vdpau. The rendering is not working right anyway, but when making the window too big I see the same stripes on the broken rendering Reducing the resolution in xonotic and trackmania nations helps and resizing windows in the VM also helps. So I am not entirely sure whether I have this bug here. I'll also attach a screenshot of the ubuntu 11.10 vm as it looks strange to me that a window with a "bad" size in a composited desktop inside virtualbox would trigger that bug.
Created attachment 51592 [details] ubuntu 11.10 beta in virtualbox, left console window: "good" size, right console window: "bad" size
Does: Option "ColorTiling" "false" in the device section of your xorg.conf help? If so, you may have an old version of the 32 bit 3D driver which doesn't handle tiling properly.
If you're really hitting the same bug, you should also have a look at https://bugs.launchpad.net/xorg-server/+bug/824346. Multi-arch is definitely the answer to this bug. But multi-arch is a bit experimental for now, if you can wait a bit (or test a beta), Ubuntu 11.10 should support it. So wait'n'see...
(In reply to comment #18) > Does: > > Option "ColorTiling" "false" > > in the device section of your xorg.conf help? If so, you may have an old > version of the 32 bit 3D driver which doesn't handle tiling properly. No, it doesn't help. I checked via Xorg.0.log and it definitely said that color tiling is disabled. xonotic still showed those stripes. For me it is definitely not the 32 bit multiarch problem because xonotic (a native 64 bit game) and a 64 bit Ubuntu in Virtualbox shows the problem too. "LIBGL_DEBUG=verbose xonotic-sdl" shows: ... libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/r600_dri.so GL_VENDOR: X.Org GL_RENDERER: Gallium 0.4 on AMD REDWOOD GL_VERSION: 2.1 Mesa 7.12-devel (git-d7cdbc3) ... It uses my 64 bit mesa git and it has the rendering problem. Does that mean it is definitively another issue and I should open a new bugreport? I only posted here because the rendering issues look very much alike, but I can't see whether they are cause by the same issue. I cannot find any error in any output...
(In reply to comment #20) > Does that mean it is definitively another issue and I should open a new > bugreport? Probably.
(In reply to comment #20) > (In reply to comment #18) > > Does: > > > > Option "ColorTiling" "false" > > > > in the device section of your xorg.conf help? If so, you may have an old > > version of the 32 bit 3D driver which doesn't handle tiling properly. > > No, it doesn't help. I checked via Xorg.0.log and it definitely said that color > tiling is disabled. xonotic still showed those stripes. I have to take this back... I completely forgot that I had set the R600_TILING variable to 1. It overrode the xorg settings. With R600_TILING=0 xonotic does render correctly. So I guess after all it is related, however it is not exactly the same issue, since it happens for some 64 bit applications with the newest mesa too. I have since tested Gnome 3.2 a bit and when what is rendered has a "bad" size it is corrupted too (the dash with the default theme on 1600x900 for example).
(In reply to comment #22) > I completely forgot that I had set the R600_TILING variable to 1. It overrode > the xorg settings. They're not directly related. Does the problem occur with Option "ColorTiling" enabled and R600_TILING=0?
(In reply to comment #23) > (In reply to comment #22) > > I completely forgot that I had set the R600_TILING variable to 1. It overrode > > the xorg settings. > > They're not directly related. Does the problem occur with Option "ColorTiling" > enabled and R600_TILING=0? No. $ grep -i tiling /var/log/Xorg.0.log [ 17.889] (**) RADEON(0): Option "ColorTiling" "on" [ 17.907] (II) RADEON(0): KMS Color Tiling: enabled $ echo $R600_TILING 0 -> Works fine. So I finally have it: R600_TILING=1 produces the rendering errors. Is it still worth a new bug report?
(In reply to comment #24) > > R600_TILING=1 produces the rendering errors. > Is it still worth a new bug report? R600_TILING=1 enables 2D tiling of textures. It's off by default because there are still some corner cases with problems like this one. Enabling 1D texture tiling may work better and likely has fewer problematic cases.
(In reply to comment #24) > R600_TILING=1 produces the rendering errors. > Is it still worth a new bug report? It's up to you, but it would basically be an enhancement request, as R600_TILING is disabled by default. This bug is very likely fixed upstream, resolving.
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.