[Mesa-dev] [PATCH 00/15] gallium/radeonsi hang debugging and IB parser

Marek Olšák maraeo at gmail.com
Sun Aug 23 05:09:02 PDT 2015

Patch 7 didn't make to the list, because it's too big:


On Sun, Aug 23, 2015 at 2:04 PM, Marek Olšák <maraeo at gmail.com> wrote:
> Hi,
> Setting GALLIUM_DDEBUG=800 (timeout=800ms) enables the new ddebug module, which records all gallium states. The module tries to detect a hang and if it occurs, it prints all gallium states to a file, and calls pipe_context->dump_debug_state, which prints driver-specific state to the same file. The module exactly pinpoints the problematic draw call, because it waits for every draw call to finish within the given timeout.
> The result on the radeonsi driver is a report that contains the following:
> - the problematic draw call with all gallium states
> - memory mapped status registers for hang debugging (GRBM_STATUS, etc.)
> - disassembled shaders
> - the indirect buffer (IB, AKA command buffer or CS) in a human-readable form
> The driver also adds trace points to indirect buffers, and it prints where the CP stopped executing the IB. You can either read it with "less -R" or convert to html with "aha".
> This is the html report from one GPU hang. You can see the trace points in the IB there. The CP is probably stuck at PS_PARTIAL_FLUSH, waiting for the 3D engine to go idle:
> http://people.freedesktop.org/~mareko/ddebug_heaven_hung.html
> Most of the IB parser is automatically generated from sid.h using a python script invoked during a Mesa build, so it understands all packets and all registers which are defined there. It's regenerated when sid.h is changed.
> One more html report just showing how many status registers are printed on VI:
> http://people.freedesktop.org/~mareko/ddebug_dump.html
> Please review.
> Marek

More information about the mesa-dev mailing list