Fix capture deadlock when vkQueuePresentKHR unlocks a CPU wait
#1708
Conversation
In a situation where you have two threads: - one waiting on a synchronization primitive (`VkSemaphore`, `VkFence`....) - another on which a call to `vkQueuePresentKHR` is necessary to signal that primitive Then if the "CPU waiting call" (`vkWaitForFences`, `vkWaitSemaphores`...) is reached by thread 1 before `vkQueuePresentKHR` is reached by thread 2, the `api_call_mutex_` of the `CaptureManager` is locked by the CPU waiting call which makes it impossible to lock by the call to `vkQueuePresentKHR` (which is always an exclusive lock) and we end up in a deadlock situation. I don't see why the lock inside `vkQueuePresentKHR` should be exclusive, so I propose to solve this issue by simply using the same system of shared lock as for all the other calls. Change-Id: I3b8e9e9c569b578564fa3529d42800b586f54191
|
CI gfxreconstruct build queued with queue ID 249192. |
|
CI gfxreconstruct build # 4760 passed. |
1 similar comment
|
CI gfxreconstruct build # 4760 passed. |
|
An additional change would be needed here to release the shared lock and acquire the exclusive lock when trimming is activated by a present call. Recently, I was looking at the exclusive locks in present due to a noticeable perf impact they have on some DX12 applications. An earlier version of the code used a shared lock in present and then acquired the exclusive lock when activating trimming. The exclusive locks were moved to the present calls by 6bf1a6a and 500bb7c to avoid a deadlock issue, which looks to have been caused by two threads acquiring the shared lock and then attempting to acquire the exclusive lock without releasing the shared lock. I have a local change to acquire the shared lock on present and then release it before acquiring the exclusive lock when activating trimming, which has been going through testing and should be ready for submission soon. This change wouldn't necessarily replace what you have here but could be added on top of it. |
bradgrantham-lunarg
added
the
P1
This bug can be observed when capturing the Khronos Vulkan-Sample "timeline_semaphore"
In a situation where you have two threads:
VkSemaphore,VkFence....)vkQueuePresentKHRis necessary to signal that primitiveThen if the "CPU waiting call" (
vkWaitForFences,vkWaitSemaphores...) is reached by thread 1 beforevkQueuePresentKHRis reached by thread 2, theapi_call_mutex_of theCaptureManageris locked by the CPU waiting call which makes it impossible to lock by the call tovkQueuePresentKHR(which is always an exclusive lock) and we end up in a deadlock situation.I don't see why the lock inside
vkQueuePresentKHRshould be exclusive, so I propose to solve this issue by simply using the same system of shared lock as for all the other calls.