渲染传递同步作用域的vkCmdPipelineBarrier澄清
在被以前的修订弄糊涂之后，我看到了以下关于vulkan规范的更新说明
如果
vkCmdPipelineBarrier记录在呈现传递实例之外，则第一个同步作用域包含所有在提交顺序较早时发生的命令。如果在呈现传递实例中记录了vkCmdPipelineBarrier，则第一个同步作用域仅包括在同一子传递中以较早的提交顺序出现的命令。在这两种情况下，第一个同步作用域仅限于srcStageMask指定的源级掩码确定的流水线级上的操作。 如果vkCmdPipelineBarrier记录在呈现传递实例之外，则第二个同步作用域包含所有稍后按提交顺序发生的命令。如果在呈现传递实例中记录了vkCmdPipelineBarrier，则第二个同步作用域仅包括稍后在同一子传递中按提交顺序发生的命令。在这两种情况下，第二个同步作用域仅限于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将位于第二个同步范围，对吗？换句话说，在呈现传递中使用的管道屏障的同步作用域不考虑其他子传递？只有当前的子通道？
回答 1
Stack Overflow用户
发布于 2019-10-25 17:05:00
我感到困惑的是，在第一个同步作用域未考虑呈现传递之前，它的措辞方式让我认为甚至可能是以前的命令。
他们不被考虑。直接了当。
子通道中的管道屏障将在子通道中创建命令之间的依赖关系。子传递依赖项在子传递之间创建依赖关系。外部子传递依赖项在呈现传递之前/之后创建子传递和命令之间的依赖关系。
如果子传递1在子传递0完成之前无法开始执行(因此，它们之间存在依赖关系)，那么子传递1中的任何命令都可以假定子传递0已经完成。这包括障碍。因此，这使得依赖项是传递的；子传递1中屏障之后的内容可以假设子传递0已经完成，因为子传递1中的所有内容都可以做出这样的假设。类似地，子通道中的命令(如屏障)将依赖于子传递直接或间接依赖的任何外部依赖项。
现在，由于依赖关系是基于特定阶段的，所以只有当依赖链包含实际相互依赖的阶段时，传递性才适用。
https://stackoverflow.com/questions/58562267
复制相似问题
腾讯云开发者
