Initial Public Release of AMDGPU debugger

[Nicolai Hähnle]

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 
detailed picture.

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.

Cheers,
Nicolai