Bug 48472

Summary: GPU Lockup while running demo (rzr - the scene is dead) in wine
Product: Mesa Reporter: Nathan-J. Hirschauer <nathanhi>
Component: Drivers/Gallium/r600Assignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: major    
Priority: medium CC: nathanhi
Version: git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: [PATCH] r600g: check gpr count limit

Description Nathan-J. Hirschauer 2012-04-09 10:12:19 UTC
While running Razor 1911 - Scene is dead (http://www.chiptune.com/razor/rzr-the_scene_is_dead.zip) in wine I get a GPU Lockup:

[  690.049988] radeon 0000:01:00.0: GPU lockup CP stall for more than 10233msec
[  690.049993] GPU lockup (waiting for 0x00002749 last fence id 0x00002746)
[  690.051188] radeon 0000:01:00.0: GPU softreset 
[  690.051191] radeon 0000:01:00.0:   R_008010_GRBM_STATUS=0xE5700030
[  690.051193] radeon 0000:01:00.0:   R_008014_GRBM_STATUS2=0x00110103
[  690.051195] radeon 0000:01:00.0:   R_000E50_SRBM_STATUS=0x200000C0
[  690.051202] radeon 0000:01:00.0:   R_008020_GRBM_SOFT_RESET=0x00007FEE
[  690.066201] radeon 0000:01:00.0: R_008020_GRBM_SOFT_RESET=0x00000001
[  690.082204] radeon 0000:01:00.0:   R_008010_GRBM_STATUS=0xA0003030
[  690.082206] radeon 0000:01:00.0:   R_008014_GRBM_STATUS2=0x00000003
[  690.082208] radeon 0000:01:00.0:   R_000E50_SRBM_STATUS=0x200080C0
[  690.083209] radeon 0000:01:00.0: GPU reset succeed
[  690.103443] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000).
[  690.103467] radeon 0000:01:00.0: WB enabled
[  690.134854] [drm] ring test succeeded in 1 usecs
[  690.134861] [drm] ib test succeeded in 1 usecs

I'm using mesa-git (c653287) with Linux 3.2.13 (Arch Linux) and Xorg 1.12.0.901 on a Thinkpad R500 (which has the following VGA Controller: 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV620 [Mobility Radeon HD 3400 Series] (Mobility Radeon HD 3450)

Attached the a logfile with WINEDEBUG=+wgl,+opengl. Seems like the lockup occurs while the following message appears (Line 1232): trace:opengl:wine_glDrawArrays (7, 0, 4)

I hope I attached all important files/infos - If I forgot something, let me know.
Comment 1 Nathan-J. Hirschauer 2012-04-09 10:19:23 UTC
Here is the wine-logfile: http://deepserve.info/blar/rzr-the_scene_is_dead.2.log Seems that 5MB are way too big for Bugzilla to handle.

Forgot to mention: This demo definitely runs in WINE, so this may not be a wine bug!
Comment 2 Vadim Girlin 2012-04-09 12:59:12 UTC
Created attachment 59693 [details] [review]
[PATCH] r600g: check gpr count limit

The problem is that some shader requires too much registers. I suspect it's caused by the loop unrolling. TGSI source for that shader uses 161 temps.

This patch doesn't solve the real problem, but it will prevent the lockups with r600g and allow to detect the problem by printing the error message. Also it may allow the app to run almost as expected (maybe with minor rendering problems).
Comment 3 Nathan-J. Hirschauer 2012-04-09 14:03:47 UTC
Comment on attachment 59693 [details] [review]
[PATCH] r600g: check gpr count limit

Review of attachment 59693 [details] [review]:
-----------------------------------------------------------------

Works like a charm, thanks!

Doesn't seem like there are any rendition errors at all!
Comment 4 Nathan-J. Hirschauer 2012-04-09 14:04:50 UTC
Thanks!
Comment 5 Nathan-J. Hirschauer 2012-04-09 14:05:04 UTC
-
Comment 6 cyberkm 2016-06-24 13:10:36 UTC
There are many different problems with this solution now.

examples
https://bugs.freedesktop.org/show_bug.cgi?id=84292
https://bugs.freedesktop.org/show_bug.cgi?id=50325
https://bugs.freedesktop.org/show_bug.cgi?id=93936
https://bugs.freedesktop.org/show_bug.cgi?id=68901

Maybe its the time to remove this temporary fix and solve the root problem.
As more and more games / apps come to linux and they simply don't work with mesa.

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.