About vkCmdPipelineBarrier2KHR

Hello,

in buildCommandBuffers() below

Does the location of vkCmdPipelineBarrier2KHR (A, B, C) below make differences or not ?

for (int32_t i = 0; i < drawCmdBuffers.size(); ++i)
{
vkBeginCommandBuffer

vkCmdPipelineBarrier2KHR — A

vkCmdBeginRenderingKHR

vkCmdPipelineBarrier2KHR — B

vkCmdEndRenderingKHR

vkCmdPipelineBarrier2KHR — C

vkEndCommandBuffer
}

There’s no way to answer this question, as it is unclear what the barriers are intended to accomplish, what rendering operations are being performed, the order the CBs will be submitted to the queue in, etc.

Could it matter? Sure, but I don’t understand why that would ever be in doubt.

Hello, Alfonse
Sorry for confusing in my question

What I meant is

if I put a vkCmdPipelineBarrier2KHR command (with a fixed dependencyinfo variable as its argument)
before vkCmdBeginRenderingKHR
or between vkCmdBeginRenderingKHR and vkCmdEndRenderingKHR
or after vkCmdEndRenderingKHR,
will this make difference ?

The difference is in the scope. It makes a difference whether you issue the barrier inside a render pass scope (yes, dynamic rendering counts as render pass) or outside. The man page tells you how those two scopes differ: vkCmdPipelineBarrier(3)

1 Like

Pipeline barriers create execution dependencies between two sets of commands: the ones before the barrier and the ones after it. So it seems pretty clear that exactly where the barrier is placed within the sequence of commands is important, right?

So, the existence of the question suggests to me that there’s something fundamental you don’t understand about what a pipeline barrier actually is. It feels a bit like asking if the location of vkCmdBindPipeline relative to vkCmdDraw matters. It’s a question that would only exist if you aren’t aware of what information drawing operations use to draw stuff.

So can you be more clear about what it is that prompted this question?

Hello, Sascha
Thank you for your help
From the manual you recommended, I found there is also “submission order”
I will read this manual
Have a nice day

Hello, Alfonse
As far as I know, the order of recording in the source is different from the sequence GPU runs the commands given in the queue

That is, if srcStageMask and dstStageMask remains the same, the place where vkCmdPipelineBarrier2KHR is located in the cpp source will not matter, which I guessed

However, I am just a beginner to graphic programming, so I will refer to the manual Sascha recommended above, and also will think about what you say now

Thank you and have a nice day, Alfonse

However, this is quite confusing,
as Alfonse told me several times,
I should read these statements below (OMG)

When vkCmdPipelineBarrier is submitted to a queue, it defines a memory dependency between commands that were submitted to the same queue before it, and those submitted to the same queue after it.

If vkCmdPipelineBarrier was recorded outside a render pass instance, the first synchronization scope includes all commands that occur earlier in submission order. If vkCmdPipelineBarrier was recorded inside a render pass instance, the first synchronization scope includes only commands that occur earlier in submission order within the same subpass. In either case, the first synchronization scope is limited to operations on the pipeline stages determined by the source stage mask specified by srcStageMask.

If vkCmdPipelineBarrier was recorded outside a render pass instance, the second synchronization scope includes all commands that occur later in submission order. If vkCmdPipelineBarrier was recorded inside a render pass instance, the second synchronization scope includes only commands that occur later in submission order within the same subpass. In either case, the second synchronization scope is limited to operations on the pipeline stages determined by the destination stage mask specified by dstStageMask.

When vkCmdPipelineBarrier2 is submitted to a queue, it defines memory dependencies between commands that were submitted to the same queue before it, and those submitted to the same queue after it.

The first synchronization scope and access scope of each memory dependency defined by pDependencyInfo are applied to operations that occurred earlier in submission order.

The second synchronization scope and access scope of each memory dependency defined by pDependencyInfo are applied to operations that occurred later in submission order.

If vkCmdPipelineBarrier2 is recorded within a render pass instance, the synchronization scopes are limited to a subset of operations within the same subpass or render pass instance.

Synchronization and Cache Control :: Vulkan Documentation Project