Linux 6.4 Preparing DRM Deadline Hints To Help Influence GPU Frequency/Performance

[phoronix]

Phoronix: Linux 6.4 Preparing DRM Deadline Hints To Help Influence GPU Frequency/Performance

Rob Clark on Saturday sent out a pull request adding the DMA-BUF/DMA-FENCE deadline awareness code to the Direct Rendering Manager (DRM) subsystem with the upcoming Linux 6.4 cycle...

https://www.phoronix.com/news/DMA-BUF-Fence-Deadline-6.4

[Linuxxx]

This deadline awareness support is a hint for fences so that real-time deadlines like vblanks can be communicated to the fence signaler for enhancing power/frequency management decisions. This deadline awareness support was inspired in part by handling currently done by Intel's kernel graphics driver.

Really nice if this actually will allow Vsync deadlines to not be missed.

However, from my current experience with an Intel i3-7100U NUC, using the performance governor is a must if wanting to minimize the number of dropped frames when playing a high resolution & bitrate video via mpv's Vulkan renderer, even when using VA-API hardware decoding directly (i.e. non-copy mode).

In other words, even though Intel's kernel driver already has a mechanism for Vblank deadline awareness, in practice using anything less than the performance governor (e.g. schedutil) will result in noticeably higher amounts of dropped frames.

[MadCatX]

Really nice if this actually will allow Vsync deadlines to not be missed.

However, from my current experience with an Intel i3-7100U NUC, using the performance governor is a must if wanting to minimize the number of dropped frames when playing a high resolution & bitrate video via mpv's Vulkan renderer, even when using VA-API hardware decoding directly (i.e. non-copy mode).

In other words, even though Intel's kernel driver already has a mechanism for Vblank deadline awareness, in practice using anything less than the performance governor (e.g. schedutil) will result in noticeably higher amounts of dropped frames.

Could this be the vulkan backend being premature? I recall having rather subpar experience with it. Setting the video output to "gpu-next" and profile to "gpu-hq" I get zero dropped frames with H.265-encoded HDR 4K video on a measly Vega 8.

[treba]

Workloads that interact with a periodic time based deadline, such as double buffered GPU rendering vs vblank sync'd page flipping. In this scenario, missing a vblank deadline results in an *increase* in idle time on the GPU (since it has to wait an additional vblank period), sending a signal to the GPU's devfreq to reduce frequency, when in fact the opposite is what is needed..

This should be the notorious Gnome-Shell case without the triple-buffering patches.

[Linuxxx]

Could this be the vulkan backend being premature? I recall having rather subpar experience with it. Setting the video output to "gpu-next" and profile to "gpu-hq" I get zero dropped frames with H.265-encoded HDR 4K video on a measly Vega 8.

Well, you have to keep in mind that my Intel "UHD" 620 GPU (Gen. 9.5) is even more measly than your Vega 8!

Also, I do use the Vulkan output in combination with "gpu-next", too.

When was the last time you tried the Vulkan renderer of mpv?

I also remember the OpenGL renderer of Mesa's RadeonSI being faster than RADV's Vulkan with mpv on my Radeon R9 380 dGPU.

But for about a year now I've switched to the Vulkan output there aswell, and performance hasn't been an issue ever since.

Perhaps it's worth giving it another try on your AMD APU nowadays?

[robclark]

Really nice if this actually will allow Vsync deadlines to not be missed.

However, from my current experience with an Intel i3-7100U NUC, using the performance governor is a must if wanting to minimize the number of dropped frames when playing a high resolution & bitrate video via mpv's Vulkan renderer, even when using VA-API hardware decoding directly (i.e. non-copy mode).

In other words, even though Intel's kernel driver already has a mechanism for Vblank deadline awareness, in practice using anything less than the performance governor (e.g. schedutil) will result in noticeably higher amounts of dropped frames.

IME, and maybe this is more the case with heterogeneous setups like big/little or performance/efficiency, schedutil does seem to depend on some hinting from userspace about which processes are important. It works well with android and CrOS, but there the foreground/top app is moved into a different cgroup with uclamp boost applied. Probably more distro's using schedutil need to do similar things.

[Beryesa]

This should be the notorious Gnome-Shell case without the triple-buffering patches.

I see a nice race on the horizon :P

[marlock]

folks, if my reading of the article wasn't mistaken, this work is for GPU priority hinting, same idea as the already traditional CPU priority hinting used by schedutil and its ilk, but for GPU drivers to use it

putting the CPU in performance mode helps GPU-intensive tasks if they have a chance to stall in CPU-dependant parts of the process

this helps everything else that may receive poor priority inside the GPU itself, helps GPU clocking, etc