synchronization - 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.

如果我没理解错的话，这些陈述是不是在说:

• 第一个同步范围是用于之前可以考虑同步的可能命令(来源)

• 第二个同步范围是(目标)之后可以考虑用于同步的可能命令

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

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

这些同步示例是否正确？

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

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 将在第二个同步范围内正确？换句话说，其他子 channel 不被考虑用于渲染 channel 中使用的管道屏障的同步范围？只有当前子 channel ？

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.

他们不被考虑。 直接。

子 channel 中的管道屏障将在子 channel 内的命令之间创建依赖关系。子 channel 依赖关系在子 channel 之间创建依赖关系。外部子 channel 依赖关系在渲染 channel 之前/之后创建子 channel 和命令之间的依赖关系。

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

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