Comment # 11
on bug 94900
from iive@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.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
