Summary: | GPU hang in High Fidelity | ||
---|---|---|---|
Product: | Mesa | Reporter: | Christoph Haag <haagch> |
Component: | Drivers/Gallium/radeonsi | Assignee: | Default DRI bug account <dri-devel> |
Status: | RESOLVED FIXED | QA Contact: | Default DRI bug account <dri-devel> |
Severity: | normal | ||
Priority: | medium | ||
Version: | git | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: | dmesg |
Description
Christoph Haag
2017-01-05 23:47:43 UTC
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 really should be a new trace though. Confirmed, I can reproduce the hang on my rx 480 with latest mesa/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 not 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 doesn'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 Just tried it again and it does not hang the GPU now. They changed the starting environment to another one and had many commits since I last tried, so could be the driver or the app who fixed it. |
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.