关于 Vulkan VkSubpassDependency 成员的问题
Questionst about Vulkan VkSubpassDependency members
我正在研究 Vulkan RenderPasses，出于业余爱好。
我对 VkSubpassDependency 结构的成员有以下描述。
措辞是来自来源（书籍、规范、互联网）的语言的组合，以及
我自己的文字锻造。由于我搞砸了，描述可能是错误的。
// .srcSubpass:
// The subpass index from which "producing" operations should be finished before the second set of "consuming" operations executes.
// If there are no dependencies on previous subpasses(eg: first subpass), use VK_SUBPASS_EXTERNAL.
// .srcStageMask:
// A bitmask of the pipeline stages which produce the data read by the "consuming" commands.
// .srcAccessMask:
// The types of memory operations that occurred during the "producing" commands.
// ----------
// .dstSubpass:
// The index of the first subpass whose operations depend the output of this subpass; or VK_SUBPASS_EXTERNAL, if
// there are no destination subpasses dependencies.
// .dstStageMask:
// A bitmask of the pipeline stages which depend on the data generated by the "producing" commands.
// .dstAccessMask:
// The types of memory operations that will be performed in "consuming" commands.
我有一些问题
假设一个 RenderPass 有 3 个子通道——S1、S2、S3——它们“逻辑上”按顺序执行，但 GPU 可能会乱序执行。
-
- srcSubpass:
- 1.1。有没有可能出现S3既不依赖S1也不依赖S2的场景？或者后续的子通道 总是 取决于之前的一些通道？
- 1.2。如果 1.1 为真，那么
srcSubpass 将是 VK_SUBPASS_EXTERNAL，对吗？
- 1.3。或者，
VK_SUBPASS_EXTERNAL 是否仅适用于 S1？
- 2。 dstSubpass:
- 2.1。这只是 always 下一个逻辑子通道（即：S1->S2）的索引吗？还是有可能是S1->S3？
- 2.2。与问题1.1类似，S3是否可以不依赖于S2，因此S2的这个值是
VK_SUBPASS_EXTERNAL？
- 3。 srcStageMask:
- 3.1。流水线阶段越早，两组操作之间的依赖性越小吗？
也就是说，
VK_PIPELINE_STAGE_VERTEX_INPUT_BIT 的 srcStageMask 比 VK_PIPELINE_STAGE_VERTEX_SHADER_BIT. 的依赖时间更短
- 3.2。如果 3.1 为真，那么这意味着理想的流水线阶段应该是
VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT，对吗？
- 4. dstStageMask:
- 4.1。 2组操作之间的依赖时间越小，流水线越往下越好？
- 4.2。如果 4.1 为真，那么
VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT 将是最小依赖性的理想阶段。是吗？
谢谢
1.1 根据定义，任何不是 impossible\invalid 的东西都是可能的。使用相同的顶点缓冲区渲染到两个独立的颜色附件可能有意义。可能会节省装箱，这只需要完成一次。
1.2 不一定。例如，子通道可能没有颜色附件，而是通过存储图像输出。因此它不需要 VK_SUBPASS_EXTERNAL 依赖性，无论是显式的还是隐式的。
1.3 不，它适用于首先使用给定附件的子通道，因为该子通道为该附件执行 LoadOp。
2.1 是的，它是一个依赖DAG，所以它可能有S1→S3，S2→S3（没有S1→S2）。
2.2 可能是 VK_SUBPASS_EXTERNAL。请注意，您可以有更多的依赖关系；一个可以是 VK_SUBPASS_EXTERNAL，另一个可以有另一个子通道。 S2 中的一个附件可能已完成并在此处具有早期 StoreOp，因此 VK_SUBPASS_EXTERNAL 适合它。
3.1 是的，在srcStageMask中使用了更符合逻辑的早期阶段，这种依赖性施加的限制更小或相等。
3.2 是的，那将是一个空操作依赖。巧合的是，这就是指定隐式子通道依赖性的方式。
4.1 是的，同样的逻辑。 `dstStageMask 中使用了更符合逻辑的后期阶段，这种依赖性施加的限制小于或等于。
4.2 这就是空操作依赖。巧合的是，这就是指定隐式子通道依赖性的方式。
我正在研究 Vulkan RenderPasses，出于业余爱好。
我对 VkSubpassDependency 结构的成员有以下描述。 措辞是来自来源（书籍、规范、互联网）的语言的组合，以及 我自己的文字锻造。由于我搞砸了，描述可能是错误的。
// .srcSubpass:
// The subpass index from which "producing" operations should be finished before the second set of "consuming" operations executes.
// If there are no dependencies on previous subpasses(eg: first subpass), use VK_SUBPASS_EXTERNAL.
// .srcStageMask:
// A bitmask of the pipeline stages which produce the data read by the "consuming" commands.
// .srcAccessMask:
// The types of memory operations that occurred during the "producing" commands.
// ----------
// .dstSubpass:
// The index of the first subpass whose operations depend the output of this subpass; or VK_SUBPASS_EXTERNAL, if
// there are no destination subpasses dependencies.
// .dstStageMask:
// A bitmask of the pipeline stages which depend on the data generated by the "producing" commands.
// .dstAccessMask:
// The types of memory operations that will be performed in "consuming" commands.
我有一些问题
假设一个 RenderPass 有 3 个子通道——S1、S2、S3——它们“逻辑上”按顺序执行，但 GPU 可能会乱序执行。
-
- srcSubpass:
- 1.1。有没有可能出现S3既不依赖S1也不依赖S2的场景？或者后续的子通道 总是 取决于之前的一些通道？
- 1.2。如果 1.1 为真，那么
srcSubpass将是VK_SUBPASS_EXTERNAL，对吗？ - 1.3。或者，
VK_SUBPASS_EXTERNAL是否仅适用于 S1？
- 2。 dstSubpass:
- 2.1。这只是 always 下一个逻辑子通道（即：S1->S2）的索引吗？还是有可能是S1->S3？
- 2.2。与问题1.1类似，S3是否可以不依赖于S2，因此S2的这个值是
VK_SUBPASS_EXTERNAL？
- 3。 srcStageMask:
- 3.1。流水线阶段越早，两组操作之间的依赖性越小吗？
也就是说，
VK_PIPELINE_STAGE_VERTEX_INPUT_BIT的srcStageMask比VK_PIPELINE_STAGE_VERTEX_SHADER_BIT. 的依赖时间更短
- 3.2。如果 3.1 为真，那么这意味着理想的流水线阶段应该是
VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT，对吗？
- 4. dstStageMask:
- 4.1。 2组操作之间的依赖时间越小，流水线越往下越好？
- 4.2。如果 4.1 为真，那么
VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT将是最小依赖性的理想阶段。是吗？
谢谢
1.1 根据定义，任何不是 impossible\invalid 的东西都是可能的。使用相同的顶点缓冲区渲染到两个独立的颜色附件可能有意义。可能会节省装箱，这只需要完成一次。
1.2 不一定。例如，子通道可能没有颜色附件，而是通过存储图像输出。因此它不需要 VK_SUBPASS_EXTERNAL 依赖性，无论是显式的还是隐式的。
1.3 不，它适用于首先使用给定附件的子通道，因为该子通道为该附件执行 LoadOp。
2.1 是的，它是一个依赖DAG，所以它可能有S1→S3，S2→S3（没有S1→S2）。
2.2 可能是 VK_SUBPASS_EXTERNAL。请注意，您可以有更多的依赖关系；一个可以是 VK_SUBPASS_EXTERNAL，另一个可以有另一个子通道。 S2 中的一个附件可能已完成并在此处具有早期 StoreOp，因此 VK_SUBPASS_EXTERNAL 适合它。
3.1 是的，在srcStageMask中使用了更符合逻辑的早期阶段，这种依赖性施加的限制更小或相等。
3.2 是的，那将是一个空操作依赖。巧合的是，这就是指定隐式子通道依赖性的方式。
4.1 是的，同样的逻辑。 `dstStageMask 中使用了更符合逻辑的后期阶段，这种依赖性施加的限制小于或等于。
4.2 这就是空操作依赖。巧合的是，这就是指定隐式子通道依赖性的方式。