what is your point here exactly?
?
I don't understand what you're trying to report here. What is "the issue"?
if one user dedicated thread is calling present ( in terms of DX11 ) and another vk queue thread is calling waitForIdle, you will get VK_ERROR_DEVICE_LOST from waitForIdle!
...and that happens how exactly? DXVK literally drains and locks the queue before calling vkDeviceWaitIdle to prevent that exact scenario from happening.
Why Concurrent Present + DeviceWaitIdle Is Dangerous
vkQueuePresentKHR interacts with the window system integrator (WSI) which is external to Vulkan. The present operation may not be considered "queue work" in the traditional sense — it's a handoff to the compositor. The driver may:
Block vkQueuePresentKHR internally waiting for vsync or a free swapchain image
Hold internal locks that vkDeviceWaitIdle also needs
Leave the present queue in a state where it's never truly "idle" from the driver's perspective
This is why the spec strongly implies (and drivers enforce) that you should serialize access to the device when mixing present operations with device-level synchronization.
This discussion isn't going anywhere.
you should serialize access to the device when mixing present operations with device-level synchronization.
We are already doing that. Please at least understand the code before reporting nonsense.
Nothing extracted yet.
https://github.com/doitsujin/dxvk/blob/6c7162fb10e1efb6e31e8cc3eb09a4afd6954e88/src/dxvk/dxvk_device.cpp#L689
or you will get random VK_ERROR_DEVICE_LOST !