Patch 7 didn't make to the list, because it's too big: http://cgit.freedesktop.org/~mareko/mesa/commit/?h=ddebug&id=f282ecc33e8b7ca5a058dda4e48c1d0f795e90df
Marek On Sun, Aug 23, 2015 at 2:04 PM, Marek Olšák <mar...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
