This only works if we know the actual refresh rate of the display.
However, in a wine virtual desktop or with proton's fshack, this
is often not the case, so we'd see a 60 Hz mode on a high-refresh
rate display and never actually enable the limiter.
vkAcquireNextImageKHR is a blocking call, so doing this immediately after
presentation may reduce the amount of time that passes between the application
requesing presentation and presentation actually happening on the Vulkan device.
Idea based on PR #2075.
From the spec:
"Host access to all VkQueue objects created
from device must be externally synchronized"
We were not doing that, which could cause hangs and
all sorts of issues when recreating the swap chain
on Nvidia GPUs.
According to the Vulkan spec:
> Several WSI functions return `VK_ERROR_SURFACE_LOST_KHR` if the
> surface becomes no longer available. After such an error, the surface
> (and any child swapchain, if one exists) **should** be destroyed, as
> there is no way to restore them to a not-lost state.
So if we get this error, we need to recreate the surface in addition to
the swapchain.
Philip Rebohle
Joshua Ashton
Chip Davis