RenderingDevice: Wait for present if supported (Vulkan Windows/X11/Wayland - needs testing) #94973
Conversation
alvinhochun
force-pushed
the
rd-wait-for-present
branch
from
4902c3e to
f04ea48
Compare
alvinhochun
changed the title
alvinhochun
force-pushed
the
rd-wait-for-present
branch
from
f04ea48 to
dc42a87
Compare
| return; | ||
| } | ||
|
|
||
| uint64_t wait_present_id = swap_chain->present_id - latency; |
There was a problem hiding this comment.
Should we be subtracting latency here? Shouldn't we just use the present id as given? The documentation for vkWaitForPresentKHR says:
vkWaitForPresentKHR waits for the presentId associated with swapchain to be increased in value so that it is at least equal to presentId.
So if wait_present_id is too low, presumably vkWaitForPresentKHR won't perform the wait, thus we won't see an improvement in latency.
There was a problem hiding this comment.
If it uses the latest present id then it will only ever be queueing one present image in the swap chain. I may be wrong here but my understanding is that, when swapchain_image_count is set to, say 3, one is always held as the front buffer, the remaining 2 images can be acquired, drawn onto and queued for present. We want to queue two images, but only wait until the first in queue is presented.
Though this made me realize the code actually need to subtract one from the latency to get the desired effect.
|
Unfortunately it looks like support for VK_KHR_present_wait is even worse than for Is there a way we could take the semaphore/fence from |
NVIDIA on Linux does not support mailbox V-Sync (at least in my experience on X11), so I'd still appreciate having support for I get this on 555.58.02: |
|
Hmm, yeah, I checked again and it looks like some nVidia configurations support it, and some don't on Linux, even on newer drivers. The ones that do indicate support seem to be GTX 900 series or newer, mostly. I wonder if it's only available in Wayland? |
|
There should also be some kind of support on X11 since https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19279, and it seems since https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27275 |
|
Seems to be working fine here on Intel HD 5500 with a slightly patched Mesa driver, both X11 and Wayland. |
|
Can you try this with my latency tester app? https://github.com/KeyboardDanni/godot-latency-tester |
Tested it with KWin + KDE Plasma on X11. Mind that I don't know if the cursor is hardware or not. I am using system Mesa 24.1.4 to test without present wait, and Mesa main branch to test with present wait, (Doesn't work on Wayland - it doesn't move the cursor.) ScreenshotsKWin (X11) with compositing, windowed, without present wait:
KWin (X11) with compositing, windowed, with present wait:
KWin (X11) without compositing, windowed, without present wait:
KWin (X11) without compositing, windowed, with present wait:
KWin (X11) without compositing, fullscreen, without present wait:
KWin (X11) without compositing, fullscreen, with present wait:
|
|
These are some excellent gains on X11! This should probably also be tested with some amount of CPU + GPU load. I'll see if I can incorporate this into the tester. |
Naive attempt to extend #94960 to support Vulkan using the
VK_KHR_present_waitextension. I have no idea how functional this is since I cannot test it correctly. (The only environment I can test this on is Windows + NVIDIA Optimus, which doesn't show any real improvements.)It needs to be especially tested with multiple windows on separate monitors, with different refresh rates.
To verify that present wait is in use, run with
--verboseand check forVK_KHR_present_wait.