Re: [PATCH V9] drm/xe/uapi: Use hint for guc to set GT frequency

[Rodrigo Vivi <rodrigo.vivi@intel.com>]

On Wed, Feb 12, 2025 at 03:38:06PM +0000, Teres Alexis, Alan Previn wrote:
> On Wed, 2025-02-12 at 17:48 +0530, Tejas Upadhyay wrote:
> > Allow user to provide a low latency hint. When set, KMD sends a hint
> > to GuC which results in special handling for that process. SLPC will
> > ramp the GT frequency aggressively every time it switches to this
> > process.
> > 
> > We need to enable the use of SLPC Compute strategy during init, but
> > it will apply only to processes that set this bit during process
> > creation.
> > 
> > Improvement with this approach as below:
> > 
> > Before,
> > 
> > :~$ NEOReadDebugKeys=1 EnableDirectSubmission=0 clpeak --kernel-latency
> > Platform: Intel(R) OpenCL Graphics
> >   Device: Intel(R) Graphics [0xe20b]
> >     Driver version  : 24.52.0 (Linux x64)
> >     Compute units   : 160
> >     Clock frequency : 2850 MHz
> >     Kernel launch latency : 283.16 us
> > 
> > After,
> > 
> > :~$ NEOReadDebugKeys=1 EnableDirectSubmission=0 clpeak --kernel-latency
> > Platform: Intel(R) OpenCL Graphics
> >   Device: Intel(R) Graphics [0xe20b]
> >     Driver version  : 24.52.0 (Linux x64)
> >     Compute units   : 160
> >     Clock frequency : 2850 MHz
> > 
> >     Kernel launch latency : 63.38 us
> > 
> > UMD Compute PR : https://github.com/intel/compute-runtime/pull/794
> > UMD Mesa PR :  https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33214
> > 
> might be a silly question: looking at the UMD patches, am i reading it wrong but it looks like the UMDs are just going
> to always enable low latency hint (as long as hw/kernel supports it)?

This flag makes a lot of sense for Compute, so they might always enabled that indeed.
For Mesa side they always enable, when user has selected certain config. But the default
there is to never use it.

> I mean if that is the system level direction, then
> why require a method for user-space to request, just always enable in kernel?

We have considered the option of always setting the flag when LR VM is in use,
that would cover compute. But the i915 experience shows that it is bad to do
implicit choices like that. Let's make it an explicit opt-in.

And that can be used for Mesa for instance if user is interested in some specific
cases that are bursty and latency sensitive, like using Mesa Vulkan for compute stuff ;)

> or is UMD supposed to expose an extention
> or something for the system integrator supposed to selectively modify app code?

Yes, I'd love to have that. One of my long term goals is to convince the high
level APIs that we need extensions. That nobody better than the apps to hint
the low level kernel, firmware and hardware about their power, performance
and latency needs. So we could stop the heuristics and guessing games
underneath!

Thanks,
Rodrigo.

> 
> ...alan