| Bug ID | 99292 |
|---|---|
| Summary | GPU hang in High Fidelity |
| 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 | haagch@frickel.club |
| QA Contact | dri-devel@lists.freedesktop.org |
Created attachment 128789 [details]<=
/span>
dmesg
RX 480 with llvm 4.0.0svn_r291124, mesa git, Linux 4.10-rc2
It works for some time, but randomly clicking through the UI with the addre=
ss
bar hangs the GPU.
Here is an apitrace (18 Megabyte):
https://ha=
agch.frickel.club/files/interface.trace.xz
This is same trace like in closed bug 99191 that no driver could run = normaly.
Oops, it has the same name, so I overwrote the other one. It r= eally should be a new trace though.
Confirmed, I can reproduce the hang on my rx 480 with latest m= esa/llvm. It hangs at draw call 680247, looks like an infinite loop in the fragment shader.
Someone said that with mesa with --enable-debug it runs in an = assert before the gpu hang happens, so I tried it to add it to the bug report, but this did n= ot happen for me. I get no assert and the GPU still hangs with --enable-debug. Just an idea, since High Fidelity has had the other known application side rendering bug, it's possible there is a buggy shader that the compiler does= n't catch.
I don't know if it's still the same problem but now it always = happens *very* quickly after starting the app. Here's a fresh api trace: https://= haagch.frickel.club/files/interface-2.trace.xz
| What | Removed | Added |
|---|---|---|
| Resolution | --- | FIXED |
| Status | NEW | RESOLVED |
Just tried it again and it does not hang the GPU now. They changed the starting environment to another one and had many commits s= ince I last tried, so could be the driver or the app who fixed it.