Pipeline Barriers

I have a problem to understand some parameters of the VkCmdPipelineBarrier.
What is the meaning of “srcStageMask” and “dstStageMask”? Source/destination of what? The terms source and destination are a bit confusing for me since (I think) they are no “transfer operation”.
Same for VkImageMemoryBarrier. What is the meaning of “srcAccessMask” and “dstAccessMask” ?


It works under the assumption that you want to get something somewhere. But it could have as well been prev
ext or before\after.

Let’s just say you made an image by op1 (source) and you need that image later in op2 (destination). There sorta is a “transfer” there. Firstly (by bit of a 4D thinking) you do have to make sure the image is not at “destination” before the “source” can create it (i.e. Execution Dependency through *StageMask). Secondly (where the sorta-transfer happens) it has to bubble down from the cache hierarchy to general purpose memory, and potentially transfered to special-purpose memory or cache the op2 is able to use (i.e. Memory Dependency through use of the ED + *AccessMask).

PS: I think it really pays of to read the spec on this. It is about one page (but you potentially have to read it like 50x before you understand). It is really important to get this theory right, and it is one of the few concepts in Vulkan where you cannot just wing it (at least if and until Validation Layers can catch this solidly and give useful messages).

I think I got it now. So just to be sure: src/dst-stageMask refers to which stage the image currently is and to which stage it should move. src/dst-AccesMask refers to the memory bind to the image. Form which type of memory “layout” it currently is, to which type it should be. Just like image layout. Am I right?

If so, I thought that those stages where unidirectional: from VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT to VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT. According to the spec, there are other stages than the graphics one. Especially the transfer ones. So how do they insert themselves into the graphics pipeline? (hope I’m clear enough)

I find your description potentially misleading.

There’s not necessarily any “move” there. It is “source” because that stage of some command produces some data to the image\buffer the “destination” will later need.

The Execution dependency of the pipeline barrier is making sure the “source” stage (and any logically earlier stage) of any previously recorded command is executed before the “destination” stage (and any logically later stage) of any subsequently recorded command. Otherwise the data written by “source” does not necessarily exist yet when the “destination” needs it, because the “source” was not executed yet.

The raw Execution dependency does not cover Memory dependecies though. It is tricky, because we are not exposed to Memory dependecies in high-level programming languages, so it feels foreign. There is many underlying reasons to potentially need a Memory dependecy, but lets think of it in terms of a Cache hierarchy. The srcAccessMask makes sure the needed data is flushed from the source. The dstAccessMask makes sure the necessary data is invalidated for the destination.


As for the pipelines, there are several types of them:

For the graphics pipeline, the following stages occur in this order:


For the compute pipeline, the following stages occur in this order:


For the transfer pipeline, the following stages occur in this order:


For host operations, only one pipeline stage occurs, so no order is guaranteed:


As you can see the transfer is different pipeline than the graphics. So they do not “insert themself” in any way.