Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Looking at pipeline stages

A dissemination of pipeline stages and how they interract with barriers and other sync operations in Vulkan™.

In my understanding of pipeline stages they are units of execution that run semi-independently. The vkCmd* commands operate on one or more stages. Copy and clear operations for example run on the TRANSFER stage. Each stage can however can work on multiple commands at a time.

When a synchronization operation is issued like vkCmdPipelineBarrier or vkCmdSetEvent and in subpass dependencies you need to specify a srcStageMask. This signifies which pipeline stages to wait on before doing the sync, in case of vkCmdSetEvent setting the event to signaled. This allows the sync to only wait on certain stages.

The dstStageMask on the other hand specifies which stages need to wait on the sync operation (plus any layout transitions and cache flushes) to complete, the other stages will continue executing. In vkSubmitInfo and vkCmdWaitEvent the mask indicates which stages wait on the semaphore or event.

In short this means that if you always say ALL_COMMANDS for the masks then you will be creating pipeline bubbles and delays when it is probably not needed.

Each command uses some stages described by a stageMask. Each dependency concerns 2 sets of commands where the second set needs to wait for the first set. When a synchronization is issued each command in the second set where its stageMask has at least one bit in common with the dstStageMask of the dependency will wait for completion of all commands in the first set whose stageMasks have at least one bit in common with the srcStageMask. This includes another dependency's dstStageMask and the pWaitDstStageMaskss of the pWaitSemaphores. Other commands using other stages will not be synchronized relative to the synchronization operation.


For example to render to a presentable image after acquiring it you need to transition it away from the present layout and into a layout compatible with being a color attachment.

If you render directly to the image then only the COLOR_ATTACHMENT_OUTPUT needs to wait on this transition. So what you can do is make the transition with a srcStageMask and dstStageMask of VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT. In the vkSubmitInfo you put the semaphore of vkAcquireNextImage in pWaitSemaphores and put the same stage mask in the matching pWaitDstStageMasks. That way any other buffer copies or clears and related transitions can start earlier than if you used ALL_COMMANDS throughout.

* add example using offscreen buffer when transfering control from host to device.
* add diagrams

This is a small writeup meant to illustrate a concept from the Vulkan™ api. This is for informational purposes only and could be completely wrong.

The Khronos group is allowed to use it in whole or in part for future updates of the vulkan specification or for another api.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment