For resource transitions, you need to know the 'before' and 'after' VkImageLayout
of the resource (eg. in the VkImageMemoryBarrier
passed to vkCmdPipelineBarrier
). Vulkan does not guarantee any ordering of execution of command buffers, unless explicitly stated in the API documentation (from this answer). However, vkCmdPipelineBarrier
does explicitly say that it creates a dependency between commands in the command buffer, before and after the call. So it is possible to 'know' the layout of an image at any point when it is transitioned within a single command buffer.
However, vkQueueSumbit
does not enforce the execution order of command buffers. If there are two command buffers, each with vkCmdPipelineBarrier
calls transitioning the same image to different layouts, is there any dependency between these two operations, or is explicit synchronization required in this situation?
Section 2.2.1 says:
Command buffer boundaries, both between primary command buffers of the same or different batches or submissions as well as between primary and secondary command buffers, do not introduce any implicit ordering constraints. In other words, submitting the set of command buffers (which can include executing secondary command buffers) between any semaphore or fence operations plays back the recorded commands as if they had all been recorded into a single primary command buffer, except that the current state is reset on each boundary.
In section 6.4, it states that the pairs of commands for synchronizations include:
First set: commands before a pipeline barrier.
Second set: commands after that pipeline barrier in the same queue (possibly limited to within the same subpass).
Note that it says "in the same queue", not "in the same command buffer".
Both of these statements make it clear that pipeline barriers affect the queue's execution of commands. Execution dependencies are not limited to a single command buffer's commands.