vk_poll_commands busy waits causing excess CPU usage

When using vk_poll_commands, the nvidia driver will busy wait and cause CPU to spike. No other vulkan driver seems to do this. This can negatively affect applications that rely on vk_poll_commands, such as using interpolation in mpv. See relevant mpv bug report here: Microstutters with Vulkan on Nvidia with interpolation · Issue #6738 · mpv-player/mpv · GitHub

Nvidia-bug-report.sh output: https://0x0.st/zaZW.gz

vk_poll_commands is a libplacebo function, which uses vkWaitForFences.
[url]https://github.com/haasn/libplacebo/blob/master/src/vulkan/command.c[/url]
Did you ask the libplacebo devs if there’s more to know about this?

I talked with the libplacebo devs about this, but apparently I misunderstood some things, I just spoke with them again and got a better picture of what’s happening:

  1. vk_poll_commands() polls each command with vk_cmd_polls()
  2. vk_cmd_polls() is a simple wrapper vkWaitForFences()

For my issue, interpolation requires heavy use of vk_poll_commands() which causes heavy use of vkWaitForFences(). That function is implemented as a busy wait loop which artificially spikes CPU. The libplacebo devs have previously tracked down this issue and identified this behavior with vkWaitForFences() as an issue. Basically, no other driver implements vkWaitForFences() as a busy wait. Simply increasing the timeout for vk_poll_commands() causes a drop in CPU usage.

Here is a vulkan trace log of mpv playing a video: https://0x0.st/zaKd.log

Here is some more information related to this issue. Both mpv devs and libplacebo devs have identified this as an issue with nvidia drivers only.

I was given this patch to libplacebo that changes the polling frequency from 1 ms to UINT64_MAX, which drastically reduces CPU usage.

This comment from a libplacebo/mpv dev summarizes the issue