[Intel-xe] [PATCH v2 2/2] drm/xe/pmu: Enable PMU interface

[Iddamsetty, Aravind]

On 07-07-2023 11:38, Dixit, Ashutosh wrote:
> On Thu, 06 Jul 2023 20:53:47 -0700, Iddamsetty, Aravind wrote:
>>
> 
> Hi Aravind,
> 
Hi Ashutosh,

> I will look at the timing stuff later but one further question about the
> requirement:
> 
>>> Also, could you please explain where the requirement to expose these OAG
>>> group busy/free registers via the PMU is coming from? Since these are OA
>>> registers presumably they can be collected using the OA subsystem.
>>
>> L0 sysman needs this
>> https://spec.oneapi.io/level-zero/latest/sysman/api.html#zes-engine-properties-t
>> and xpumanager uses this
>> https://github.com/intel/xpumanager/blob/master/core/src/device/gpu/gpu_device.cpp
> 
> So fine these are UMD requirements, but why do these quantities (everything
> in this patch) have to exposed via PMU? I could just create sysfs or an
> ioctl to provide these to userland, right?

PMU is enhanced interface to present the metrics, it provides low
latency reads compared to sysfs and one can read multiple events in a
single shot and it will give timestamps as well which sysfs cannot
provide and which is one of the requirements of UMD. Also UMDs/
observability tools do not want to have any open handles to get these
info so ioctl is dropped out.

the other motivation to use PMU in xe is the existing tools like
intel_gpu_top will work with just a minor change.
> 
> I had this same question about i915 PMU which was never answered. i915 PMU
> IMO does truly strange things like sample freq's every 5 ms and provides
> software averages which I thought userspace can easily do.

that is a different thing nothing to do with PMU interface

Thanks,
Aravind.
> 
> I don't think it's the timestamps, maybe there is some convention related
> to the cpu pmu (which I am not familiar with).
> 
> Let's see, maybe Tvrtko can also answer why these things were exposed via
> i915 PMU.
> 
> Thanks.
> --
> Ashutosh
> 
> 
>>>
>>> The i915 PMU I believe deduces busyness by sampling the RING_CTL register
>>> using a timer. So these registers look better since you can get these
>>> busyness values directly. On the other hand you can only get busyness for
>>> an engine group and things like compute seem to be missing?
>>
>> The per engine busyness is a different thing we still need that and it
>> has different implementation with GuC enabled, I believe Umesh is
>> looking into that.
>>
>> compute group will still be accounted in XE_OAG_RENDER_BUSY_FREE and
>> also under XE_OAG_RC0_ANY_ENGINE_BUSY_FREE.
>>>
>>> Also, would you know about plans to expose other kinds of busyness-es? I
>>> think we may be exposing per-VF and also per-client busyness via PMU. Not
>>> sure what else GuC can expose. Knowing all this we can better understand
>>> how these particular busyness values will be used.
>>
>> ya, that shall be coming next probably from Umesh but per client
>> busyness is through fdinfo.