Initial Public Release of AMDGPU debugger
nhaehnle at gmail.com
Mon Feb 13 10:58:53 UTC 2017
On 13.02.2017 03:39, Dave Airlie wrote:
> Is there any plans or would it be possible to add some sort of info on what you
> are looking at with UMR. Say the GRBM busy states what sort of meaning
> can be extracted from the percentage values etc, can you say with how busy
> some of the blocks are what should be done next to try and optimise things
> or to look for problems etc.
Honestly, I think the GRBM bits are a bit too coarse-grained to give you
a lot of information for performance work.
You can say some extremely rough things, like if VGT is busier than CB,
you know that something's the issue with geometry processing, but I'm
not sure it's much more help than that.
Similarly, you _might_ be able to tell how far down the pipeline the
hang is. (FWIW, the wave debugging is actually pretty cool, e.g. it can
help you isolate bugs where a shader has an infinite loop.)
I think part of the issue is that for a block to count as idle for the
purpose of GRBM, it really has to be _completely_ idle. If block A is
stalled waiting on block B, both blocks will show as busy in the GRBM
status. The performance counters, i.e. GALLIUM_HUD, can give you a more
I'd say that for performance work, umr is about the level where you
might whip it out for an extremely rough view of the situation, similar
to how you'd whip out top to get an extremely rough view of what's
happening on the CPU. It's useful, but many/most times, you'll need
something else to go deeper.
More information about the amd-gfx