[PATCH 0/7] drm/xe: Per client usage

[Lucas De Marchi]

On Tue, Apr 23, 2024 at 09:44:58AM GMT, Tvrtko Ursulin wrote:
>>For the drm client busyness that we are discussing here, the VF 
>>specific interface is still wip. The quanta ratio is more of a 
>>engine busyness concept (see below) that I presume will be used here 
>>as well.
>
>I did not follow you here.
>
>Current proposal for withing a VF per client view settled at 
>drm-cycles and drm-total-cycles, where the latter was explained will 
>move by the amount of GPU ticks in the VFs assigned quanta and be 
>static.
>
>I was just mentioning one idea for an alternative which is time based 
>and AFAICT behaves the same.
>
>Doesn't matter much since in both cases we are talking about one new 
>key, but may be handy if you start with the elapsed time based key for 
>a PF and then later, for VF support, just add one new key 
>(drm-gpu-time-ratio), instead of VF using a different pair 
>(cyles+total-cycles) than the PF (drm-engine-*).

I think the problem could be exposing the quanta in this part of the
code. I checked the wip interface again and I'm not confident we can
simply read it, as opposed to the counter that we are going to get from
GuC with it already scaled.

I just send a new version with drm-total-cycles. I see the following
benefits:

1) drm-total-cycles detach the calculation from the sleep() in the
    userspace so should even be a better approximation of the utilization

2) drm-gpu-time-ratio means it could work with the current userspace
    tools as is for native/PF, as long as they don't implement a different
    interface per driver, which seems to be the case in some of them).
    The drm-gpu-time-ratio is more an extension to the current api rather
    than a replacement

I'm not sure really which of them is better, but in doubt I stick to (1)
and sent a v2. Even if we go with (2), the changes on both kernel and
gputop would not be so big.

Lucas De Marchi