Repository navigation
fix(vk): the presenter thread is off by default again - #2544
Merged
Merged
Conversation
A review of the presenter thread (NotRexed#2325) found two problems that make it unsafe as a default: - The game thread's vkAcquireNextImageKHR runs on the swapchain while the presenter thread calls vkQueuePresentKHR and vkWaitForPresentKHR on it, with no lock shared between them. All three need the swapchain externally synchronized, and this overlap happens every frame. - The drain before a swapchain is made again gives up after 5 s, and its callers then destroy the swapchain and semaphores the presenter may still be using. The presenter's own worst case is over 5 s. RX_VK_PRESENT_THREAD=1 still turns it on. Off, the device makes no queue for it, as before NotRexed#2325. Fixes follow in their own change. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A review of the presenter thread merged in #2325 found two problems that make it unsafe as a default, so this turns it off again until they are fixed.
vkAcquireNextImageKHRruns while the presenter thread callsvkQueuePresentKHRandvkWaitForPresentKHRon the same swapchain. All three need the swapchain externally synchronized. The overlap happens every frame, by design.present_outlets two presents go out of order.What changes
RX_VK_PRESENT_THREADis off unless set to1. Off, the device makes no queue for the presenter, so the device and the presents are as they were before perf: a frame critical-path recorder (HOS_CHAIN), and an opt-in presenter thread that takes NVIDIA's present wait off the game's thread #2325.tests/test_present_thread.pysay it is off by default. The test also checks that no queue is made for it while it is off.The fixes (one lock or an idle wait around the swapchain's acquire and present, a drain that never gives up and leaves the swapchain alone, and the smaller findings) follow in their own PR. That PR turns the default back on only if every fix holds and is tested.
Tested:
tests/test_present_thread.py,tests/test_fps_stats.pyandtests/test_present_semaphores.pypass, and the Vulkan back end builds.