https://bugs.freedesktop.org/show_bug.cgi?id=64471
Priority: medium Bug ID: 64471 Assignee: dri-devel@lists.freedesktop.org Summary: Radeon HD6570 lockup in Brütal Legend Severity: major Classification: Unclassified OS: Linux (All) Reporter: zboszor@pr.hu Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI
Created attachment 79165 --> https://bugs.freedesktop.org/attachment.cgi?id=79165&action=edit Lockup from "new game"
I tried Brütal Legend on Fedora 18/x86_64, the game itself if i386. The system has these newer-than-Fedora18 components: kernel 3.9+ (commit 51a26ae7a14b85c99c9be470c2d28eeeba0f26a3) libdrm 2.4.44 from 2.4.44-2.fc20 SRPM from Koji recompiled on F18 llvm-3.3 from May 7, before branching to 3.3 was done mesa 9.2 from May 7, commit was around 03ef60681e61a52dee7fa3285618c313cf13f50c compiled into an RPM with float textures enabled:
$ rpm -q mesa-libGL mesa-libGL-9.2-0.1.fc18.x86_64 mesa-libGL-9.2-0.1.fc18.i686
The game makes the Radeon chip lock up, reliably at the same point, which is when the game starts after the long cutscene.
Attached are two dmesgs, showing the same lockup. The first occurred when I started a new game and watched through the cutscene. The second occurred when I tried to continue the auto-saved game.
https://bugs.freedesktop.org/show_bug.cgi?id=64471
--- Comment #1 from Zoltán Böszörményi zboszor@pr.hu --- Created attachment 79166 --> https://bugs.freedesktop.org/attachment.cgi?id=79166&action=edit Lockup from "continue"
https://bugs.freedesktop.org/show_bug.cgi?id=64471
--- Comment #2 from Alex Deucher agd5f@yahoo.com --- Does disabling hyperZ help? set env var R600_HYPERZ=0
https://bugs.freedesktop.org/show_bug.cgi?id=64471
--- Comment #3 from Zoltán Böszörményi zboszor@pr.hu --- Yes, it does. Thanks.
Now it doesn't lock up but the reflection of fire(? it must be fire, considering the surroundings) on the face of the hero is wrong. It looks metallic and can be described as bad rendering. (It is a different bug.)
I had these set previously, but I can see they are gone from the r600g sources:
$ set | grep R600 R600_ENABLE_S3TC=1 R600_STREAMOUT=1 R600_TILING=1
Now, which R600_DEBUG options do you suggest running the game with, so I can provide you with more in-depth information?
https://bugs.freedesktop.org/show_bug.cgi?id=64471
--- Comment #4 from Zoltán Böszörményi zboszor@pr.hu --- FYI, the "r600g: force full cache for hyperz" patch is in the source of my RPMs.
https://bugs.freedesktop.org/show_bug.cgi?id=64471
--- Comment #5 from Zoltán Böszörményi zboszor@pr.hu --- The lockup also happens with mesa commit 0b5b3f8816f9cb5a2b2259176b4c7dd9e4d31233 and llvm-3.3, whatever commit it is at in current Fedora 19 beta.
https://bugs.freedesktop.org/show_bug.cgi?id=64471
Alex Deucher agd5f@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Radeon HD6570 lockup in |Radeon HD6570 lockup in |Brütal Legend |Brütal Legend with HyperZ Product|DRI |Mesa Version|XOrg CVS |git Component|DRM/Radeon |Drivers/Gallium/r600
https://bugs.freedesktop.org/show_bug.cgi?id=64471
Alex Deucher agd5f@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thomas.lindroth@gmail.com
--- Comment #6 from Alex Deucher agd5f@yahoo.com --- *** Bug 64933 has been marked as a duplicate of this bug. ***
https://bugs.freedesktop.org/show_bug.cgi?id=64471
Nicholas Miell nmiell@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nmiell@gmail.com
--- Comment #7 from Nicholas Miell nmiell@gmail.com --- Also affects Double Fine's The Cave
https://bugs.freedesktop.org/show_bug.cgi?id=64471
Andre Heider a.heider@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |a.heider@gmail.com
--- Comment #8 from Andre Heider a.heider@gmail.com --- Seeing the same thing on "The Cave" with -rc3 and recent Mesa
https://bugs.freedesktop.org/show_bug.cgi?id=64471
Alex Deucher agd5f@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |johannes.hirte@datenkhaos.d | |e
--- Comment #9 from Alex Deucher agd5f@yahoo.com --- *** Bug 71046 has been marked as a duplicate of this bug. ***
https://bugs.freedesktop.org/show_bug.cgi?id=64471
--- Comment #10 from Johannes Hirte johannes.hirte@datenkhaos.de --- Also seen on HD 6530D, but it's not only the HyperZ. After disabling it the game works, but there are still screen corruptions.
https://bugs.freedesktop.org/show_bug.cgi?id=64471
--- Comment #11 from Johannes Hirte johannes.hirte@datenkhaos.de --- Created attachment 88389 --> https://bugs.freedesktop.org/attachment.cgi?id=88389&action=edit Xorg.log with HyperZ enabled and GPU lockup on HD 6530D
https://bugs.freedesktop.org/show_bug.cgi?id=64471
--- Comment #12 from Andre Heider a.heider@gmail.com --- I tried this game again and the issue is still present. Tested with 3.12 and recent mesa (head: f0f202e6b764be803470e27cba9102f14361ae22).
However, with a current apitrace it's now possible to trace and replay it on r600g to provoke the GPU reset. Using past apitraces makes the game work without traces/glitches. I'm using apitrace head 0227203a229e85f98a491c6b9480c0bc210f1dbb, I didn't test if a replay with older versions yields the hang.
I've uploaded a trace here (~260MiB): http://static.hackmii.com/dhewg/brutalz.trace.xz
Replaying that without R600_HYPERZ reliably reproduces GPU hangs on my BARTS card. Replaying it with R600_HYPERZ=0 makes the hangs go away, but you'll see glitches on the hero's face (effects like described above).
Note: Trace is 1920x1200 fullscreen. Windowed mode or different resolutions didn't always lockup. I tried to trim the trace down, but apitrace choked on it.
https://bugs.freedesktop.org/show_bug.cgi?id=64471
--- Comment #13 from edmondo@eriadon.com --- Issue reproduced reliably on Radeon HD5850 (Evergreen) with default settings.
Kernel: 3.12 Libdrm: 2.4.50 Mesa: 10.0.1
https://bugs.freedesktop.org/show_bug.cgi?id=64471
--- Comment #14 from Edmondo Tommasina edmondo@eriadon.com ---
Just for the log.
Kernel, libdrm and mesa updated. Issue reproduced with HYPERZ active.
Kernel: 3.13.0 Libdrm: 2.4.51 Mesa: 10.0.2
OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD CYPRESS OpenGL core profile version string: 3.1 (Core Profile) Mesa 10.0.2 OpenGL core profile shading language version string: 1.40 OpenGL version string: 3.0 Mesa 10.0.2 OpenGL shading language version string: 1.30
https://bugs.freedesktop.org/show_bug.cgi?id=64471
--- Comment #15 from Samir Ibradžić sibradzic@gmail.com --- I have the similar issue with radeonsi. The problem is bit more severe on si, cause whole X session would die, probably due to glamor...
Kernel: 3.13.0 Libdrm: 2.4.52+git128e74 Mesa 10.1.0-devel (git-dc00ec1)
OpenGL renderer string: Gallium 0.4 on AMD TAHITI OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.1.0-devel (git-dc00ec1 saucy-oibaf-ppa+curaga) OpenGL core profile shading language version string: 3.30
Starting Brutal Legend with disabled HyperZ makes the problem go away: R600_DEBUG=nohyperz ./.local/share/Steam/SteamApps/common/BrutalLegend/Buddha.bin.x86
https://bugs.freedesktop.org/show_bug.cgi?id=64471
--- Comment #16 from Hamish Wilson hamish@icculus.org --- Bug still occurs with a Radeon HD 5750 on Fedora 20 x86_64 running Linux 3.12.9 and Mesa 9.2.5. Disabling HyperZ by entering "export R600_HYPERZ=0" into a terminal before launching Brütal Legend stops the crashes.
Interestingly, it does not show up with my Radeon HD 4670 on Arch i386 running Linux 3.12.9 and Mesa 10.0.3 - although it should be noted that the problem was still not in evidence before I upgraded the system to the latest stable version of Mesa.
https://bugs.freedesktop.org/show_bug.cgi?id=64471
--- Comment #17 from Laurent carlier lordheavym@gmail.com --- I can also reproduce the lockup with a Pitcain card mesa-git/llvm-svn with Brutal Legend game. Disabling hyperz fix the issue.
I've uploaded a trace here: http://pkgbuild.com/~lcarlier/traces/BrutalLegend.trace.tar.xz
With this one i can reproduce the lockup.
https://bugs.freedesktop.org/show_bug.cgi?id=64471
Andreas Boll andreas.boll.dev@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |75112
https://bugs.freedesktop.org/show_bug.cgi?id=64471
--- Comment #18 from Hamish Wilson hamish@icculus.org --- Is everyone that is having issues using x86_64? The main difference between my Arch system and the Fedora 20 system is that I am using i386 instead.
https://bugs.freedesktop.org/show_bug.cgi?id=64471
--- Comment #19 from Nicholas Miell nmiell@gmail.com --- The Cave will now reliably crash the (Radeon HD 6770) GPU with HyperZ disabled.
https://bugs.freedesktop.org/show_bug.cgi?id=64471
--- Comment #20 from Edmondo Tommasina edmondo@eriadon.com --- (In reply to comment #18)
Is everyone that is having issues using x86_64? The main difference between my Arch system and the Fedora 20 system is that I am using i386 instead.
Yes, I'm using x86_64.
https://bugs.freedesktop.org/show_bug.cgi?id=64471
--- Comment #21 from Michel Dänzer michel@daenzer.net --- (In reply to comment #19)
The Cave will now reliably crash the (Radeon HD 6770) GPU with HyperZ disabled.
Please file your own report for that. This report is about Brütal Legend, which only seems problematic with HyperZ enabled.
https://bugs.freedesktop.org/show_bug.cgi?id=64471
--- Comment #22 from Samir Ibradžić sibradzic@gmail.com --- yes, x86_64 here as well
https://bugs.freedesktop.org/show_bug.cgi?id=64471
--- Comment #23 from Zoltán Böszörményi zboszor@pr.hu --- x86_64 here, too.
https://bugs.freedesktop.org/show_bug.cgi?id=64471
--- Comment #24 from Marek Olšák maraeo@gmail.com --- Thanks a lot for the apitrace.
Temporary workaround that shouldn't decrease htile Z performance is here: http://lists.freedesktop.org/archives/mesa-dev/2014-August/066519.html
https://bugs.freedesktop.org/show_bug.cgi?id=64471
--- Comment #25 from Edmondo Tommasina edmondo@eriadon.com --- Tested-By: Edmondo Tommasina
Applied PATCH 1/6, tested with R600_HYPERZ=1 and it fixes lockup.
Test environment:
Kernel: 3.16.1 Libdrm: 2.4.56 Mesa: from git (83503f9e) + your PATCH 1/6
OpenGL renderer string: Gallium 0.4 on AMD CYPRESS OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.4.0-devel (git-8f06d72) OpenGL core profile shading language version string: 3.30
HUGE THANKS Marek!
https://bugs.freedesktop.org/show_bug.cgi?id=64471
--- Comment #26 from Marek Olšák maraeo@gmail.com --- The patch has been committed, but it's a workaround, not a fix. I think this bug should remain open until a proper fix has been found.
https://bugs.freedesktop.org/show_bug.cgi?id=64471
--- Comment #27 from Clément Guérin geecko.dev@free.fr --- Latest Arch Linux with today's mesa-git and llvm-git, I'm getting a GPU lockup after the intro, when beating up the three druids. HD 7950
I tried without HyperZ and with the lowest visual settings but it doesn't change anything.
https://bugs.freedesktop.org/show_bug.cgi?id=64471
--- Comment #28 from Clément Guérin geecko.dev@free.fr --- Here's an apitrace that makes my computer hang: http://ge.tt/7RmQXf72/v/0?c
https://bugs.freedesktop.org/show_bug.cgi?id=64471
--- Comment #29 from Clément Guérin geecko.dev@free.fr --- Woops, sorry, this is out of place. Should I open another bug in the radeonsi section?
https://bugs.freedesktop.org/show_bug.cgi?id=64471
--- Comment #30 from Alexandre Demers alexandre.f.demers@gmail.com --- (In reply to Clément Guérin from comment #29)
Woops, sorry, this is out of place. Should I open another bug in the radeonsi section?
I would indeed open a new bug since this one and its comments seem related to r600g only.
https://bugs.freedesktop.org/show_bug.cgi?id=64471
Marek Olšák maraeo@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #31 from Marek Olšák maraeo@gmail.com --- (In reply to Marek Olšák from comment #26)
The patch has been committed, but it's a workaround, not a fix. I think this bug should remain open until a proper fix has been found.
Let's close this. I have enough apitraces to reproduce the issue.
dri-devel@lists.freedesktop.org