Vulkan-Docs | The Vulkan API Specification and related tools | REST library

You need to transfer your image from the undefined layout in which it starts to a presentable image format, depending on what exactly you're doing with it. For example, if you're using it as a texture in a shader, it needs to be in SHADER_READ_ONLY_OPTIMAL layout.

You can do this in multiple ways, one of them being an image memory barrier that you can submit to a transient queue. And you absolutely need to do this after recreating your swap chain, because your entire context is invalidated by the window resize operation.

Vulkan 7.1.

If srcSubpass is equal to VK_SUBPASS_EXTERNAL, the first synchronization scope includes commands that occur earlier in submission order than the vkCmdBeginRenderPass used to begin the render pass instance.

vkAcquireNextImageKHR is not in the first synchronization scope of the subpass dependency, because it's not a command submitted to a queue.

The semaphore synchronizes the stages. As the image transition happens at the beginning of the color output stage, it comes after the semaphore is signaled. As both wait for the VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT, operations from this stage before the semaphore are chained to the transition dependencies. Only by this chain the subpass dependency can know when the image was acquired to perform the transition. The writes in the output stage actually depend on the transition then, not directly on the semaphore.

Indeed, since we are going to WRITE into the attachment, there is no need to use a WRITE_BIT (meaning make writes available) in the dstAccessMask.

I am not exactly sure of your logic here. It should be WRITE exactly because we are going to write to the attachment.

It would perhaps help describe what is happening here (from krOoze/Hello_Triangle/doc):

The VkSubpassDependency chains of the the semaphore (via pWaitDstStageMask). Then it performs its layout transition. Then it syncs with the Load Op. (Then Load Op happens in the subpass. And subpass vkDraws some stuff into the swapchain image.)

Now assumably (as is typical for first use of the swapchain image) our Load Op is VK_ATTACHMENT_LOAD_OP_CLEAR. That means VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT + VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT access.

So:

1. Presentation is gonna read the swapchain image, and submit a semaphore signal.

2. We chain our VkSubpassDependency to the signal (via pWaitDstStageMask). Semaphore signal already covers all memory accesses, therefore our srcAccessMask = 0.

3. The Dependency performs its implicit dependency to the Layout Transition (takes your src, and invents some internal dst), then Layout Transition happens, which reads the image and writes it back, then the dependency performs another implicit Dependency (invents some src that covers the layout transition, and uses your dst).

4. The Load Op happens in the subpass, and you have to make sure explicitly it happens-after everything above. So your dst in your Dependency must be VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT + VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT to cover the Load Op.

Now, there are three types of memory hazards: read→write, write→write, and write→read (and read→read is a non-hazard). In WWH something writes a resource, while some other write also writes it. It is not clear which write happens last, so the memory contents becomes garbage. In RWH and WRH read and write may happen at the same time. It is not clear if the read sees the unmodified memory, or the written one (i.e. it reads garbage).

Without an explicit dependency, the Layout Transition and the subsequent Load Op form a write→write hazard. Therefore dstAccessMask must not be 0 to resolve the hazard and make sure one write happens-before the second one.

(It is perhaps worth noting we introduce the VkSubpassDependency solely for the sake of the layout transition. Otherwise the semaphore wait would already be all that is needed. The default is srcStageMask = TOP_OF_PIPE, which means without explicit Dependency the layout transition could happen before the semaphore wait, i.e. before presentation finishes reading it; that would be a read→write hazard).

To me, the layout transition must appear at the end of the presentation, and just before the beginning of the COLOR_ATTACHMENT_OUTPUT stage. And the end of presentation, for me, should be represented by BOTTOM_OF_PIPE and not COLOR_ATTACHMENT_OUTPUT

We have little bit of choice here: pWaitDstStageMask = dependency.srcStageMask = ?

Now our situation is this:

The problem was being caused because when i created the attachment descriptors, I set the storeOp and loadOp enums of the renderpass to eDontCare so the depth buffer was UB for me.

As suggested in the comments by @solidpixel. The solution is to make the first eStore and the second 'eLoad'.

I go over this a bit at krOoze/Hello_Triangle/doc. What is supposed to happen in this scenario is:

Particularly I can't find how to interpret this "dependency from that same stage to itself".

Now, lets first take care of this issue. This is what I like to call cart-before-horse intuition of the synchronization system.

You do not "synchronize stages" or something like that. That is intuition that will only cause you confusion. You synchronize scopes.

People also confuse a pipeline with a flow-chart. There is a huge intuition difference. In flow-chart, you start at a start, then you go over all the stages in order, then you are finished and forever done. That is not what pipeline is. It never starts, and never finishes. Pipeline just is. It is like a desktop game board. You stuff commands through the pipeline, and they go through the stages like pegs on the board.

A synchronization command is something that introduces a dependency between two things: between the source synchronization scope and destination synchronization scope. It guarantees the src scope happens-before the dst scope.

A scope is some subset of queue operations, and at what stage they currently their execution can be at.

So, with this better intuition,

You can use a Resource on any queue family (without a transfer) as long as you do not mind that the data becomes undefined. You still need a Semaphore to make sure there is no memory hazard.

Ye olde spec:

NOTE

If an application does not need the contents of a resource to remain valid when transferring from one queue family to another, then the ownership transfer should be skipped.

Examples do not mention it, because they are only examples.

As for synchronization (which is a separate problem from QFOT), a semaphore signal which is part of vkQueueSubmit covers everything previously in submission order. So when you submit the copy you would let it wait on the Semaphore that the last draw submitted has signaled. That means that draw and any previous draw on that queue is finished, before the copy can start on the other queue.

Then you signal a semaphore by the copy, and wait on it on the first next draw you submit. That means the copy finished writing, before the draw (and any subsequent draw) reads it on the graphics queue.

e.g.: