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

["Dixit, Ashutosh" <ashutosh.dixit@intel.com>]

On Thu, 06 Jul 2023 20:53:47 -0700, Iddamsetty, Aravind wrote:
>

Hi Aravind,

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?

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.

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.