vkCmdPipelineBarrier 对 renderpass 同步范围的澄清

Question

在被之前的修改搞糊涂后看vulkan spec，看到下面更新的对vkCmdPipelineBarrier的说明：

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.

如果我没理解错的话，这些说法是不是说：

第一个同步范围是用于之前可以考虑同步的可能命令（来源）
第二个同步范围是（目标）

并且唯一发生变化的是，当在渲染通道中使用管线屏障时，其他子通道中的命令不会被考虑用于任一同步范围。

令我感到困惑的是它的措辞方式让我认为甚至在渲染通道之前的先前命令都没有被考虑用于第一个同步范围。（与第二个之后相同）

这些同步示例是否正确？

如果在渲染过程之外，我会做类似的事情：

1. transfer;
2. computeDispatch;
3. beginRenderPass;
...
endRenderPass;

pipelineBarrier(...);

4. computeDispatch;
5. beginRenderPass;
...
endRenderPass;

命令1、2、3会在pipelineBarrier中考虑之前进行同步，即在第一个同步范围内，命令4、5会在之后考虑，即在第二个同步范围内。

如果我有以下命令列表：

1. transfer;
2. computeDispatch;
3. beginRenderPass;
   3.1 next subpass;
       3.1.1 bindPipeline;
       3.1.2 bindDescriptor;
       3.1.3 bindVertexBuffer;

       pipelineBarrier(...);

       3.1.4 bindIndexBuffer;
       3.1.5 drawIndexed;
endRenderPass;

4. computeDispatch;
5. beginRenderPass;
...
endRenderPass;

命令1、2、3.1.1、3.1.2和3.1.3将在第一个同步范围内，3.1.4和3.1.5、4、5将在第二个同步范围内。

最后，文本的粗体部分表示如果我执行以下操作：

1. transfer;
2. computeDispatch;
3. beginRenderPass;
   3.1 first subpass;
       3.1.1 bindPipeline;
       3.1.2 bindDescriptors;
       3.1.3 bindVertexBuffer;
       3.1.4 draw;
   3.2 next subpass;
       3.2.1 bindPipeline;
       3.2.2 bindDescriptor;
       3.2.3 bindVertexBuffer;

       pipelineBarrier(...);

       3.2.4 bindIndexBuffer;
       3.2.5 drawIndexed;
   3.3 next subpass;
       3.3.1 bindPipeline;
       3.3.2 bindDescriptors;
       3.3.4 draw;
endRenderPass;

4. computeDispatch;
5. beginRenderPass;
...
endRenderPass;

命令1,2,3.2.1,3.2.2,3.2.3会在第一次同步范围，命令3.2.4,3.2.5,4,5会在第二次同步范围正确吗？换句话说，其他子通道不被考虑用于渲染通道中使用的管道屏障的同步范围？只有当前子通道？

Answer 1

What I'm confused about is the way it is worded made me think that maybe even previous commands, before the render pass were not considered for the first synchronization scope.

他们不被考虑。直接.

子通道中的管道屏障将在子通道内的命令之间创建依赖关系。子通道依赖关系在子通道之间创建依赖关系。外部子通道依赖性在子通道和命令之间创建依赖性 before/after 渲染通道。

如果子通道 1 在子通道 0 完成之前无法开始执行（因此，它们之间存在依赖关系），则子通道 1 中的任何命令都可以假定子通道 0 已完成。这包括障碍。所以这使得依赖关系传递；子通道 1 中屏障之后的东西可以假设子通道 0 已完成，因为子通道 1 中的 everything 可以做出该假设。类似地，子通道中的命令（如屏障）将依赖于子通道直接或间接依赖的任何外部依赖项。

现在，因为依赖关系是基于特定阶段的，所以传递性仅适用于依赖链包含实际相互依赖的阶段的情况。

vkCmdPipelineBarrier 对 renderpass 同步范围的澄清

vkCmdPipelineBarrier clarification on renderpass synchronization scopes

synchronization

vulkan