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.