Commen=
t # 11
on bug 94900<=
/a>
from iive@yahoo.com
I'd ask you to try and narrow down the issue.
Get the program `apitrace`. Set `R600_DEBUG=3Dnosb` and use apitrace with s=
ome of
the games that cause a crash. It should produce a trace file. That trace fi=
le
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 f=
ps
and keep scenes simple. e.g. lock the dpm in low power mode, set vblank/vsy=
nc,
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 m=
ouse button on
a frame or just double click) to replay to a specific frame. Find out the f=
rame
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 dr=
aw
calls could cause a lockup, because they are the one that execute the shade=
rs
(usually 1 vertex and 1 pixel/fragment).
At this point you can upload the archived trace file somewhere (usually tra=
ces
are quite big) and tell us the location and the number of the call that cau=
ses
the lockup.
Doing this saves a lot of time to the developers, because each lookup repla=
ys
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 mu=
ch
and that you report the correct call number for the file you upload).
---
Optionally, you can also start `qapitrace` with `R600_DEBUG=3Dnosb` and loo=
kup
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=3Dsbdry,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 a=
nd
crash the system.
The "ps,vs" options would dump the disassembly of the pixel and v=
ertex 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=3Dps,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.