| Summary: | r600 [CEDAR]: GPU stalls when running shadertoy "ladybug" | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Gert Wollny <gw.fossdev> |
| Component: | Drivers/Gallium/r600 | Assignee: | mesa-dev |
| Status: | RESOLVED NOTABUG | QA Contact: | mesa-dev |
| Severity: | normal | ||
| Priority: | medium | CC: | mirh, russianneuromancer |
| Version: | git | ||
| Hardware: | Other | ||
| OS: | All | ||
| URL: | https://www.shadertoy.com/view/4tByz3 | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
dmesg of Radeon HD 6620G hang
Screenshot on CEDAR with gallium HUS |
||
|
Description
Gert Wollny
2018-02-28 14:15:28 UTC
Created attachment 137739 [details]
dmesg of Radeon HD 6620G hang
Same issue here when running on SUMO iGPU with Linux 4.15.5 and Mesa 18.1 git. Not reproducible on TURKS dGPU. Complete dmesg is attached. If running with any additional debug option is required please let me know.
You could figure out if it simply takes too long by increasing the timeout (albeit that needs a recompile of the kernel module). If so, I'm not sure what to do really. (Though I think the shader actually does spilling, possibly could eliminate some of it to speed it up, not sure though it's possible). Created attachment 137749 [details]
Screenshot on CEDAR with gallium HUS
It is actually not necessary to recompile the module, all is needed is
echo "options radeon lockup_timeout=100000" > /etc/modprobe.d/radeon.conf
and then reload the module (or reboot).
With that the shadertoy runs at 0.086 FPS (see screenshot), which means the shaders are simply to heavy for the hardware to handle within the default timeout of 10s.
The shader doesn't use many registers, even un-optimized the number is below 100, so spilling doesn't occur and beyond that I don't see any option to optimize it more (apart from rewriting the assembly manually and injecting it). Which means the only thing we could suggest to someone who wants to enjoy this shader on older hardware is to change the timeout like given above. Hence I'm closing this as NOTABUG. (In reply to Gert Wollny from comment #4) > The shader doesn't use many registers, even un-optimized the number is below > 100, so spilling doesn't occur and beyond that I don't see any option to > optimize it more (apart from rewriting the assembly manually and injecting > it). Which means the only thing we could suggest to someone who wants to > enjoy this shader on older hardware is to change the timeout like given > above. Hence I'm closing this as NOTABUG. Ah yes I see. I was thinking it was using too many regs because my browser used an older driver version, where translation failed due to too many temp regs (in fact nearly 1000...). But that's no longer the case with more recent driver stack. That shader really is from the "holy crap" department indeed, and the driver doesn't seem to do anything obviously wrong with it, so I agree hitting the timeout is expected (as a side note, things get really unresponsive here on my HD 5750...). |
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.