| Bug ID | 99019 |
|---|---|
| Summary | "Star Ruler 2" game will freeze the system |
| Product | Mesa |
| Version | 13.0 |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | major |
| Priority | medium |
| Component | Drivers/Gallium/radeonsi |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | johnz@lunarg.com |
| QA Contact | dri-devel@lists.freedesktop.org |
Overview: "Star Ruler 2" freezes the system immediately after choosing &quo= t;New Game". This forces the user to hit the reset on the computer. Steps to reproduce: The game will load to the menu screen and as soon as you double click for &= quot;New Game" the system will freeze.=20 Linux and Hardware: This problem has been experienced on Ubuntu 16.10 -- using AMD's R9 Fury, RX470, and RX470 graphic cards.=20 Mesa Builds: The problem has been reproduced on Mesa 13.0.2 (git-2722144) and Mesa 13.0.1 (git-f2f487e)
I remember this game has some shader fallback option in settings file, if = true that stopped freezing with radeonsi drivers. So seems some issue with shaders by default.
Created attachment 128387 [details]<=
/a>
Shaders
Attached those two shaders if someone wanna investigate this.
"gui_skin_ps.txt" is that default and makes driver freeze, but f=
alback one is
"gui_skin_simple_ps.txt" work fine.
Both works fine with AMD propertiary drivers.
Could you provide an apitrace that reproduces the hang? That'l= l help track this down eventually.
(In reply to Nicolai H=C3=A4hnle from comment #3) > Could you provide an apitrace that reproduces th= e hang? That'll help track > this down eventually. Here we go, just starting app and clicking on New Game: https://www.dropbox.com/s/rje3xylvyablt4p/StarRuler2-trace.xz?dl=3D0=
Confirmed, it hangs the GPU at draw call 15626. Tested on RX 4= 80 with latest mesa/llvm. Replacing gui_skin_ps.txt by gui_skin_simple_ps.txt with qapitrace fixes the hang. Not sure yet if the shader is miscompiled or if something is not currently bound.
The shader ends up in an infinite loop because of this:
...
v_cmpx_le_f32_e32 vcc, 0, v0
s_branch BB0_30
s_cbranch_execnz BB0_30
; BB#29:
exp null off, off, off, off done vm
s_endpgm
BB0_30: ; %endif110
...
s_branch shouldn't be there. It prevents killing the wave early and the loop
that follows is infinite, because it starts with EXEC=3D0.
Thanks for the info Marek, this helped me to figure out the is= sue. I have a fix locally for that hang, will think more before sending it thoug= h.
Possible fix is here https://reviews.llvm.org/D28351
| What | Removed | Added |
|---|---|---|
| Resolution | --- | FIXED |
| Status | NEW | RESOLVED |
Should be fixed by https://github.com/llvm-mirror/llvm/commit/e8e3365d526= 6760f3d7ad247f21496bb69cfef39.