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
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Reply via email to