You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the start of the frame, we want to wait until the previous frame has finished, so that the command buffer and semaphores are
available to use. To do that, we call vkWaitForFences:
As it said, we need to wait command buffers are available to use. But what does “semaphores are available to use" mean? I've checked the spec of Vulkan, it's said that binary semaphore has only two states: signaled and unsignaled. When it's signeled, it's available to unsignal, and vise versa.
After operation B begins executing, semaphore S is automatically reset back to being unsignaled, allowing it to be used again.
As quoted above, when the commands in presentQueue begin executing, imageAvailableSemaphore is automatically reset back to being unsignaled, so it's available for vkAcquireNextImageKHR in my opinion. So the only purpose of vkWaitForFences is to wait for the command buffer to be available.
According to this, vkWaitForFences can be placed anywhere before recordCommandBuffer. But that's not the case.
In both sections of the code, I tried putting vkWaitForFences after vkAcquireNextImageKHR and before recordCommandBuffer:
When I run it, the validation layer reports an error:
validation layer: Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01779 ] Object 0: handle = 0xd175b40000000013, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x5717e75b | vkAcquireNextImageKHR(): Semaphore must not have any pending operations. The Vulkan spec states: If semaphore is not VK_NULL_HANDLE it must not have any uncompleted signal or wait operations pending (https://vulkan.lunarg.com/doc/view/1.3.275.0/windows/1.3-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-semaphore-01779)
Can someone help me with this question? Is there something I am not understanding correctly?
The text was updated successfully, but these errors were encountered:
vkAcquireNextImageKHR is different than vkQueueSubmit. With vkQueueSubmit:
VUID-vkQueueSubmit-pSignalSemaphores-00067
Each binary semaphore element of the pSignalSemaphores member of any element of pSubmits must be unsignaled when the semaphore signal operation it defines is executed on the device
That means that you can call vkQueueSubmit when the signal semaphores are "currently" signalled, just so long as they become unsignalled by the time this vkQueueSubmit should signal them.
Whereas with vkAcquireNextImageKHR:
If semaphore is not VK_NULL_HANDLE, it must be unsignaled
So when you call vkAcquireNextImageKHR, the semaphore must be unsignalled no matter what, and just about the only way to do that is to wait for the fence of the frame that used that semaphore as a wait semaphore to complete (ie, the previous frame's submission).
Hello everyone, I was reading the Rendering and presentation and Frames in flight chapter, I have some questions about this code.
It makes me confused.
As it said, we need to wait command buffers are available to use. But what does “semaphores are available to use" mean? I've checked the spec of Vulkan, it's said that binary semaphore has only two states: signaled and unsignaled. When it's signeled, it's available to unsignal, and vise versa.
As quoted above, when the commands in
presentQueue
begin executing,imageAvailableSemaphore
is automatically reset back to being unsignaled, so it's available forvkAcquireNextImageKHR
in my opinion. So the only purpose ofvkWaitForFences
is to wait for the command buffer to be available.According to this,
vkWaitForFences
can be placed anywhere beforerecordCommandBuffer
. But that's not the case.In both sections of the code, I tried putting
vkWaitForFences
aftervkAcquireNextImageKHR
and beforerecordCommandBuffer
:When I run it, the validation layer reports an error:
Can someone help me with this question? Is there something I am not understanding correctly?
The text was updated successfully, but these errors were encountered: