[Bug 94900] HD6950 GPU lockup loop with various steam games (octodad, saints row 4, grid autosport)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=94900

--- Comment #11 from iive at yahoo.com ---
I'd ask you to try and narrow down the issue.

Get the program `apitrace`. Set `R600_DEBUG=nosb` and use apitrace with some of
the games that cause a crash. It should produce a trace file. That trace file
should be able to reproduce the lockup when replaying(retracing) it without the
"nosb".
(Smaller traces help with the next steps. Also use any trick to limit the fps
and keep scenes simple. e.g. lock the dpm in low power mode, set vblank/vsync,
etc)

Then try to narrow down what causes the lockup. You can use `qapitrace` GUI
program for that. Load the trace, and use "lookup state" (right mouse button on
a frame or just double click) to replay to a specific frame. Find out the frame
that causes lockup.

(E.g. lookup every 100'th frame. When you find a crash, try every 10'th
starting from last known working frame. Then lookup frames one by one.
It might be less optimal than binary search, but rebooting and reloading
probably takes more time.)

After you find the frame, try to find the exact call inside that frame that
causes the lockup. You can "look up" individual calls, just like with frames,
so use the same process. For the final narrow down you can use that only draw
calls could cause a lockup, because they are the one that execute the shaders
(usually 1 vertex and 1 pixel/fragment).

At this point you can upload the archived trace file somewhere (usually traces
are quite big) and tell us the location and the number of the call that causes
the lockup.

Doing this saves a lot of time to the developers, because each lookup replays
the trace file from the begging to the selected call. As you can see, the
process is tedious and time consuming.


(It might be good idea to trim the trace file a few frames after the first
frame that crashes, just to make it smaller. Make sure you don't cut too much
and that you report the correct call number for the file you upload).
---

Optionally, you can also start `qapitrace` with `R600_DEBUG=nosb` and lookup
the crashing draw call. That would let you see the exact vertex and fragment
(pixel) shaders that cause the problem (in GLSL form).

If you have Mesa3D compiled with debug support you may try to get the
disassembled output of the shaders.

This is done by setting `R600_DEBUG=sbdry,ps,vs` and then looking up the draw
call that crashes.

The "sbdry" option allows the "shader backend" to run, but then prevents the
use the result. This allows us to print the crashing code, but not use it and
crash the system.

The "ps,vs" options would dump the disassembly of the pixel and vertex shaders,
before and after "shader backend" (the one disabled by nosb).

Since the binary shader code is compiled and optimized by SB at first use, The
last vertex and fragment(pixel) shaders are the ones that cause the hang.

These steps are optional, because developers can easily do them on their own
and they already build mesa with debug enabled.

---

There is a faster way to get the disassembly of the crashing shaders.
Set `R600_DEBUG=ps,vs` and run the game. The last shaders that are output
should be the ones that cause the crash. You just have to be sure that the real
info is not lost at the lockup. (Getting partial log could be quite
misleading.)
---
btw, I'm not developer. Just advanced user.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160712/ed8dcfad/attachment-0001.html>