| Bug ID | 96731 |
|---|---|
| Summary | [RADEONSI] [LLVM] [bisected] GPU lockups when running Alien: = Isolation |
| Product | Mesa |
| Version | git |
| Hardware | Other |
| OS | All |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Drivers/Gallium/radeonsi |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | arek.rusi@gmail.com |
| QA Contact | dri-devel@lists.freedesktop.org |
Created attachment 1=
24784 [details]
gpu lockups part from dmesg
Hi, GPU trying reset few times but hang at the end.
ArchLinux 64
Radeon HD 7770
mesa latest from git
kernel 4.7rc
libdrm latest from git
first bad commit is:
r273467 | arsenm | 2016-06-22 22:15:28 +0200 |
AMDGPU: Fix verifier errors in SILowerControlFlow
The main sin this was committing was using terminator
instructions in the middle of the block, and then
not updating the block successors / predecessors.
Split the blocks up to avoid this and introduce new
pseudo instructions for branches taken with exec masking.
Also use a pseudo instead of emitting s_endpgm and erasing
it in the special case of a non-void return.
| What | Removed | Added |
|---|---|---|
| CC | arsenm2@gmail.com |
Matt, any ideas offhand? Arek, can you attach the stderr output from running the game with the environment variable R600_DEBUG=3Dfs,vs,gs,ps,cs,tcs,tes with and without the commit in question?
Created attachment 124796 [details]
R600_DEBUG=3Dfs,vs,gs,ps,cs,tcs,tes ./AlienIsolation for r273466
Created attachment 124797 [details]
R600_DEBUG=3Dfs,vs,gs,ps,cs,tcs,tes ./AlienIsolation for r273467
I didn't mention before but intro,loading screen and main menu= works. Game hangs right after everything is loaded.
r274275 fixes a problem I noticed while doing more work on thi= s, although I wouldn't expect it to change much
The only obvious difference I see in the dump diffs without lo= oking at any particular shader is the number of used registers changed. This is probably because previously the implicit uses of the super registers were missing wh= en the AsmPrinter counts them. If the dynamic was out of bounds, it is more li= kely to be out of bounds of the allocated VGPRs, in which case the hardware beha= vior is to return v0. If there are out of bounds accesses, it would now read an undefined register. I don't know if there are any actual out of bounds dyn= amic vector accesses
There is nothing obviously wrong with the last shader(s) in th=
e bad log - and
unfortunately, the logs are not really comparable: the first genuine differ=
ence
is in TGSI, which means that a different sequence of OpenGL calls happened =
in
the two runs. This makes it basically impossible to figure out the problem.
To make progress on this bug, could you please record an apitrace of the ga=
me,
and see if you can reproduce the lockups by playing back the trace? If this
works, please provide
1. the trace file itself (e.g. upload on Google Drive)
2. before and after logs of playing back the trace like Michel asked for.
Hi guys, replay causes gpu lockup as well.=20 apitrace is here: https://drive.google.com/open?id=3D0Bx3qMdwakiQMaTNxd0JsazA4ejA
Created attachment 124857 [details]
R600_DEBUG=3Dfs,vs,gs,ps,cs,tcs,tes apitrace replay AlienIsolation.1.trace<=
/pre>
| What | Removed | Added |
|---|---|---|
| Attachment #124857 description | R600_DEBUG=3Dfs,vs,gs,ps,cs,tcs,tes apitrace replay AlienIso= lation.1.trace | R600_DEBUG=3Dfs,vs,gs,ps,cs,tcs,tes apitrace replay AlienIso= lation.1.trace r273466 |
Created attachment 124858 [details]<=
/a>
R600_DEBUG=3Dfs,vs,gs,ps,cs,tcs,tes apitrace replay AlienIsolation.1.trace
r273467
Hi Arek, thanks for the trace and new logs! Looking at the logs, the only diff is in branch instructions. Perhaps there= is a bug in how kill instructions are lowered now? Since there are several sha= ders with differences, it's not clear yet. I'm going to try to narrow it down to= a single shader using the trace.
The first bug that I noticed in the shaders was in return hand= ling for non-monolithic shader parts. Fix for that bug is here: http://reviews.llvm.org/D21975
Nocolai, thanks for fix. That did the job. The game now looks = even better:)=20 Really! I'll try revert llvm to old revision and play it again, maybe it's = just my imagination.
| What | Removed | Added |
|---|---|---|
| CC | t.hirsch@web.de |
*** Bug 96794 has been marked as a dupl= icate of this bug. ***
| What | Removed | Added |
|---|---|---|
| Resolution | --- | FIXED |
| Status | NEW | RESOLVED |
Fixed in LLVM r274612 "AMDGPU: Fix return of non-void-ret= urning shaders".
(In reply to Michel D=C3=A4nzer from comment #1) > Matt, any ideas offhand? >=20 > Arek, can you attach the stderr output from running the game with the > environment variable >=20 > R600_DEBUG=3Dfs,vs,gs,ps,cs,tcs,tes >=20 > with and without the commit in question? For obtaining the hanging shader, setting GALLIUM_DDEBUG=3D800 and attachin= g the created log file is better. The issue would have been pretty obvious from t= hat.