Initial Public Release of AMDGPU debugger

[Tom St Denis]

On 02/12/2017 09:39 PM, Dave Airlie wrote:
>> We're pleased to announce the initial public release of the AMDGPU User Mode
>> Register debugger (umr).  This tool allows privileged users to read and
>> write GPU registers in order to diagnose, debug, and aid in development of
>> AMDGPU features.  The tool supports a variety of other commands for actions
>> such as decoding ring contents, analyzing wavefronts, viewing machine
>> status, and more.  It supports SI through VI devices and requires a very
>> recent kernel (what will be 4.10).
>>
>>
>> The tool is released publicly under a MIT open source license and is hosted
>> at
>>
>>
>> https://cgit.freedesktop.org/amd/umr/
>>
>>
>> We welcome all developers to try it out and submit feedback, suggestions,
>> bug reports, and patches to this mailing list.
>>
>>
>> The project started internally as a debug aid last year and was the driving
>> force behind the debugfs changes over the last year.   The tool has matured
>> enough that we feel the community will be best served by having access to it
>> and after having been granted permission to release it I've squashed most of
>> our internal history down to a few commits which are now available to the
>> public.
>>
>>
>> Development of the tool has been alongside the AMD staging 4.9 tree which
>> has commits slotted for 4.10 and 4.11.  Most features should work with a 4.9
>> vanilla kernel but users are recommended to really use 4.10 or newer
>> kernels.   Within reason we will try to accommodate older kernels but it is
>> not our primary focus.
>>
>>
>> Future work will be done through patches submitted to the list to foster
>> community involvement.
>
> Hi Tom,
>
> 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.

Hi Dave,

Honestly it's a bit out of my field.  Adding the bits was the easy part 
:-).  Personally I've used the power/clock counters (as well as power) 
for the various work I've done on PG/CG.  Lately, I've used it to test 
patches from others.

You can kinda get a "broad" sense of performance deltas by tracking the 
deltas in percentages between various runs but that's ultimately not 
super useful for developers unless you know what you're looking at.

Generally speaking when looking at the GRBM/TA/VGT counters you would 
need to know the components of the core and how the shaders interact 
with them (the ISA of the GPU in question).

Presumably combined with GALLIUM_HUD performance trackers (which count 
things like cache misses for instance) you could perf where the GPU is 
being busy the most and get hints on where to optimize.

Ideally combined with UMR's "logger" mode in --top and a properly 
instrumented mesa test case developers could correlate the global bits 
umr tracks with the context specific perf counters mesa can capture.

Perhaps Alex and/or the Mesa folk could offer more insight.

Sorry I couldn't be of more help though.  If nobody else from AMD joins 
in the conversation I'll raise it privately on Monday.

Cheers,
Tom