Bug 39897 - Graphical glitches in some games on Evergreen
Summary: Graphical glitches in some games on Evergreen
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r600 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
: 39877 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-08-07 05:26 UTC by russianneuromancer
Modified: 2011-10-04 09:29 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Xorg log (44.82 KB, patch)
2011-08-07 08:24 UTC, russianneuromancer
Details | Splinter Review
dmesg output (76.04 KB, application/octet-stream)
2011-08-07 08:25 UTC, russianneuromancer
Details
glxinfo output (24.54 KB, application/octet-stream)
2011-08-07 08:25 UTC, russianneuromancer
Details
BEEP screenshot (107.39 KB, image/jpeg)
2011-08-07 19:30 UTC, russianneuromancer
Details
xonotic 1600x900, glsl enabled (1.60 MB, image/png)
2011-09-25 10:36 UTC, chris
Details
ubuntu 11.10 beta in virtualbox, left console window: "good" size, right console window: "bad" size (551.02 KB, image/png)
2011-09-25 10:39 UTC, chris
Details

Note You need to log in before you can comment on or make changes to this bug.
Description russianneuromancer 2011-08-07 05:26:51 UTC
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.
Comment 1 Alex Deucher 2011-08-07 07:41:53 UTC
Is this a regression?  Please attach your xorg log, dmesg output, and glxinfo output.
Comment 2 russianneuromancer 2011-08-07 08:24:29 UTC
Created attachment 50014 [details] [review]
Xorg log
Comment 3 russianneuromancer 2011-08-07 08:25:06 UTC
Created attachment 50015 [details]
dmesg output
Comment 4 russianneuromancer 2011-08-07 08:25:49 UTC
Created attachment 50016 [details]
glxinfo output
Comment 5 russianneuromancer 2011-08-07 08:37:01 UTC
> 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
Comment 6 Sven Arvidsson 2011-08-07 09:05:06 UTC
I don't see any screenshot, did you forget to attach it?

The games you mention (BEEP, Source titles) have been working fine here.
Comment 7 Alex Deucher 2011-08-07 14:34:19 UTC
32 bit games require a 32 bit 3D driver, so make sure you also updated your 32 bit driver.
Comment 8 russianneuromancer 2011-08-07 19:30:04 UTC
Created attachment 50020 [details]
BEEP screenshot
Comment 9 russianneuromancer 2011-08-07 19:30:54 UTC
> 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.
Comment 10 Alex 2011-08-07 21:39:22 UTC
*** Bug 39877 has been marked as a duplicate of this bug. ***
Comment 11 Alex 2011-08-07 21:50:01 UTC
@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).
Comment 12 russianneuromancer 2011-08-07 23:03:44 UTC
> 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?
Comment 13 Sven Arvidsson 2011-08-08 03:38:00 UTC
(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.)
Comment 14 Alex 2011-08-08 23:30:18 UTC
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 ?
Comment 15 Alex 2011-08-13 07:11:16 UTC
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
Comment 16 chris 2011-09-25 10:36:44 UTC
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.
Comment 17 chris 2011-09-25 10:39:07 UTC
Created attachment 51592 [details]
ubuntu 11.10 beta in virtualbox, left console window: "good" size, right console window: "bad" size
Comment 18 Alex Deucher 2011-09-25 10:42:18 UTC
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.
Comment 19 Alex 2011-09-25 11:26:52 UTC
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...
Comment 20 chris 2011-09-26 03:00:53 UTC
(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...
Comment 21 Michel Dänzer 2011-09-29 09:59:33 UTC
(In reply to comment #20)
> Does that mean it is definitively another issue and I should open a new
> bugreport?

Probably.
Comment 22 chris 2011-09-30 14:41:56 UTC
(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).
Comment 23 Michel Dänzer 2011-10-03 07:48:43 UTC
(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?
Comment 24 chris 2011-10-03 09:15:35 UTC
(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?
Comment 25 Alex Deucher 2011-10-03 09:18:30 UTC
(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.
Comment 26 Michel Dänzer 2011-10-04 09:29:01 UTC
(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.