I’m a beginner and I’m learning from the tutorial: vulkan-tutorial(rendering and presentation lesson).
I don’t fully understand how pipeline works and I don’t understand: what pipeline stages can be in VK_SUBPASS_EXTERNAL if there are no other commands before the rendering pass?
The half of the dependency with VK_SUBPASS_EXTERNAL acts exactly the same as vkCmdPipelineBarrier (as far as theory goes).
srcStageMask points to the previous use of the resource (and if there is not any, then it can be empty). In case of the tutorial it would likely be vkAcquireNextImage, which passes the ball via a semaphore, which in turn is waited on in pWaitDstStageMask. And you should probably reference this wait in the dependency, in order to avoid modifying the image via layout transition before it is even acquired.
Unless the render pass is the first thing you’ve ever submitted to this queue, there are always things before the render pass. Dependencies don’t stop at command buffer, or even queue submission, boundaries.
So the command to get the image from the swapchain also goes through the pipeline? Or what?
P.S: It’s not exactly clear to me what the steps could be if there is no pipeline
Hm, yea. You need to wholistically understand the overal theory of the synchronization system otherwise your question do not quite make sense… I am not comfortable to answer it “yes” nor “no”, as it is stated.
In short, the semaphore wait happens in the pWaitDstStageMask. I.e. in a specific pipeline stage you provide in this parameter.
You didn’t mention anything about swap chain images in your post. Or the semaphores you have to use when trying to use them.
Swap chain image acquisition is not a queue operation; it is a process that is part of the display engine, which is not part of Vulkan. However, it can be tied into Vulkan via the use of a semaphore. That is, when the display engine has acquired the image, it will signal a Vulkan semaphore.
The batch you submit to the queue can wait on that semaphore, and that wait operation is a synchronization operation just like any other. So it has some destination stages that it affects.
I agree. Can you recommend a reference book where you can read about synchronization in general?
I understand that it is not necessary to look for a special meaning in the mask of the stage. It just makes it so that the subpass does not start until the semaphore signals
For authoritative information you can read the Vulkan Specification, albeit it may be harder because nobody else is doing the thinking for you and regurgitates it for you in simplified (and potentially misleading) terms.
I can’t recommend other materials since I don’t peruse them myself. And they were not even necessarily existing at the time I learned all this stuff.
The particular situation here seems to be that you vkAcquire an image, which gives you pending Semaphore, which in turn you give to vkSubmit alongside pWaitDstStage which gives you a pipeline stage. That should suffice for some surface understanding of this particular case. The chain of events that need to happen in particular order as to avoid hazards on the swapchain image are:
Right, but layout transition happens before subpass (per infographics above). Layout transition can only be restricted via the Dependency (and its src and dst parameters). Otherwisely, the semaphore wait could in of itself prevent subpass start (even without dependency), if appropriate pWaitDstStageMask was provided (Subpass Load Op happens in STAGE_COLOR for color and input attachments and STAGE_EARLY_FRAGMENT for depth attachment). Without providing a Subpass Dependency, the semaphore wait cannot itself prevent start of the layout transition, because that does not happen in any specific stage.
Again, that question does not quite make sense to me. The particular case is hopefully explained in (1). You need some mechanism to manhandle the layout transition so it is not permitted to happen at a wrong time and cause a hazard.
A pipeline is not an entity that can “wait” on something. You might be mistaking the concept of a Pipeline with the concept of a Finite State Machine. The diagram for both concepts can look similarly, but they are semantically different. FSM can perhaps be instantiated, and wait on other things. Pipeline always exists and operations flow through it. A dependency introduced by a synchronization primitive says which operation is not allowed to overtake another operation while racing through the pipeline (or resp. in this case allowed to reach a certain stage of the pipeline).
I understand the basic concepts and hopefully more understanding will come with experience. Thank you!
This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.
