On Mon, Feb 28, 2022 at 6:33 AM Tvrtko Ursulin
<tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote:
On 25/02/2022 22:14, Rob Clark wrote:
On Fri, Feb 25, 2022 at 12:25 PM Rob Clark <robdclark@xxxxxxxxx> wrote:
From: Rob Clark <robdclark@xxxxxxxxxxxx>
Similar to AMD commit
874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
infrastructure added in previous patches, we add basic client info
and GPU engine utilisation for msm.
Example output:
# cat /proc/`pgrep glmark2`/fdinfo/6
pos: 0
flags: 02400002
mnt_id: 21
ino: 162
drm-driver: msm
drm-client-id: 7
drm-engine-gpu: 1734371319 ns
drm-cycles-gpu: 1153645024
Nice, so my vendor agnostic actually worked (with that single fixup of
accounting for the fact pdev tag is optional)?
Note that it might be useful to have a standardized way to report # of
cycles and max freq, so userspace tool can derive %utilization in
addition to just %busy
How do you define %utilisation vs %busy - I don't exactly follow since I
see the two as same?
so, say you are running at 50% of max clk, and gpu is busy 70% of the
time. The utilization is only 35% because the gpu could scale up the
clk to get more work done.
Looking at your patch I guess I don't understand the difference between
'elapsed' and 'cycles' inside your retire_submit(). Both are scoped to a
single context and are not global? If 'elapsed' is time context has
spent on the GPU, cycles isn't the same just in a different unit?
Correct, we capture (from GPU cmdstream) two counters both before and
after a submit (aka execbuf) runs, one is a fixed-rate counter, which
gives us elapsed time. The second is a counter that increments every
clk cycle, which gives us the # of cycles. With the two values, we
can calculate GPU frequency.
BR,
-R
Regards,
Tvrtko