CODEWITHSUNDEEP
vulkan
audi02
audi02

Reputation: 661

Can vkQueuePresentKHR be synced using a pipeline barrier?

The fact vkQueuePresentKHR gets a queue parameter makes me think that it is like a command that is delivered to the queue for execution. If so, it is possible to make it waits (until the writing into the image to be presented is finished) using a pipeline barrier where source stage is VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT and destination is VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT. Or maybe even by an image barrier to ease the sync constraint for the image only.

But the fact that in every tutorial and books the sync is done using semaphore , makes me think that my assumption is wrong. If so, why vkQueuePresentKHR needs a queue parameter ? because the semaphore parameter is seems to be enough: when it is signaled, vkQueuePresentKHR can present the image according to the image index parameter and the swapchain handle parameter.

Upvotes: 2

Views: 493

Answers (2)

Nicol Bolas
Nicol Bolas

Reputation: 473272

Presentation is a queue operation. That's why you submit it to a queue. A queue that will execute the presentation of the image. And specifically to a queue that is able to perform present operations.

As for how to synchronize... the specification is a bit ambiguous on this point.

Semaphores are definitely able to work; there's a specific callout for this:

Semaphores are not necessary for making the results of prior commands visible to the present:

Any writes to memory backing the images referenced by the pImageIndices and pSwapchains members of pPresentInfo, that are available before vkQueuePresentKHR is executed, are automatically made visible to the read access performed by the presentation engine. This automatic visibility operation for an image happens-after the semaphore signal operation, and happens-before the presentation engine accesses the image.

While provisions are made for semaphores, there is no specific statement of other things. In particular, if you don't wait on a semaphore, it's not clear what "happens-after the semaphore signal operation" means, since no such signal operation happened.

Now, the API for vkQueuePresentKHR makes it clear that you don't need to provide a semaphore to wait on:

waitSemaphoreCount is the number of semaphores to wait for before issuing the present request.

The number may be zero.

One might think that, as a queue operation, all prior synchronization on that queue would still affect presentation. For example, an external subpass dependency if you wrote to the swapchain image as an attachment. And it probably would... if not for one little problem.

See, synchronization is ultimately based on dependencies between stages. And presentation... doesn't have a stage. So while your source for the external dependency would be well-understood, it's not clear what destination stage would work. Even specifying the all-stages flag wouldn't necessarily work.

Does "not a stage" exist in the set of all stages?

In any case, it's best to just use a semaphore. You'll probably need one anyway, so just use that.

Upvotes: 2

krOoze
krOoze

Reputation: 13246

There are couple of outstanding Issues against the specification. Notably KhronosGroup/Vulkan-Docs#1308 is exactly your question.

Meanwhile everyone usually follows this language:

The processing of the presentation happens in issue order with other queue operations, but semaphores have to be used to ensure that prior rendering and other commands in the specified queue complete before the presentation begins.

Which implies semaphore has to be used. And given we are not 110 % sure, that means semaphore should be used until we know any better.

Another semi-official source is the sync wiki, which uses a semaphore.

Despite what this quote says, I think it is reasonable to believe it is also permissible to use other sync that makes the image already visible before the vkQueuePresent, such as fence wait.

But just pipeline barriers are likely not sufficient. The presentation is outside the queue system:

However, the scope of this set of queue operations does not include the actual processing of the image by the presentation engine.

Additionally there is no VkPipelineStageFlagBit for it, and vkQueuePresentKHR is not included in the submission order, so it cannot be in the synchronization scope of any vkCmdPipelineBarrier.

The confusing part is this unfortunate wording:

Any writes to memory backing the images referenced by the pImageIndices and pSwapchains members of pPresentInfo, that are available before vkQueuePresentKHR is executed, are automatically made visible to the read access performed by the presentation engine.

I believe the trick is the "before vkQueuePresentKHR is executed". As said above, vkQueuePresentKHR is not part of submission order, therefore you do not know if the memory was or wasn't made available via a pipeline barrier before the vkQueuePresentKHR is executed.

Upvotes: 4

Related Questions