带有屏障或渲染通道的移动图像布局答案

【问题标题】：Moving image layouts with barrier or renderpasses带有屏障或渲染通道的移动图像布局
【发布时间】：2018-12-26 08:01:53
【问题描述】：

vulkan 文档提到，与使用屏障（即vkCmdPipelineBarrier）移动它们相比，渲染通道中的移动图像布局（参见VkAttachmentDescription 结构）是首选。我可以理解，因为后者引入了限制并行执行的同步点。

现在考虑一个典型的例子：从VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL 到VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL 的转换。在这种情况下，资源将在着色器中读取，但为了安全地执行此操作，有必要将颜色附件的写入与着色器中的读取同步。换句话说，无论如何我们都需要使用屏障，并且在渲染过程中移动布局似乎根本没有任何优势。

能以某种方式详细解释这一切是如何运作的吗？在哪些情况下，在渲染通道中移动布局具有真正的优势？是否存在不需要进一步同步的（实际）布局更改？

【问题讨论】：

这叫做“过渡”而不是“移动”。
我可以得到规范中推荐的报价。我好像没找到。
我明白了，它确实不在规格中。我从 Vulkan 编程指南中得到了这个。那本书也使用了“移动”而不是“过渡”。
您可以（甚至应该）使用渲染通道依赖项在渲染通道内部和之后同步操作，而不是管道屏障。它们正是为此目的而设计的。

标签： vulkan

【解决方案1】：

首先，您没有选择权。 API 强制您提供finalLayout 和中间VkAttachmentReference::layouts。您可以有条件地在渲染通道内使用vkCmdPipelineBarrier（又名子通道自依赖），但其中一条规则是不允许更改附加的布局图片：

如果使用VkImageMemoryBarrier，则在屏障中指定的图像和图像子资源范围必须是当前子通道中帧缓冲区使用的图像视图之一的子集。此外，oldLayout必须等于newLayout，srcQueueFamilyIndex 和dstQueueFamilyIndex必须为VK_QUEUE_FAMILY_IGNORED。

因此，在渲染过程中，您只能使用渲染过程机制更改布局，或者您必须在渲染过程之外。只剩下“外部渲染通道”的情况来讨论：

考虑渲染通道的好方法是它（可能基于平台）将资源（使用loadOp）复制到专用内存，然后在完成后将其复制回（使用storeOp）回通用-目的记忆。

话虽如此，有理由假设您可以免费将布局转换为finalLayout，作为storeOp 的一部分。（类似地，从initialLayout 到第一个VkAttachmentReference::layout 的转换是loadOp 的一部分。）因此，如果可能\足够方便，将布局转换作为渲染通道的一部分是有意义的。

【讨论】：

感谢您的回复！我知道 finalLayout 不是可选的。但是我想可以将 finalLayout 设置为“VK_IMAGE_LAYOUT_GENERAL”，以防当时还不知道正确的布局。稍后可以使用屏障过渡到正确的布局。我现在了解到您的回答，这种方法可能效率较低。
@S.Jordan GENERAL 几乎没有意义 —无论如何，您总是需要同步。同步。 cmds 总是提供布局转换作为它们的一部分，因此您不妨提供所需的特定布局（不需要它的 GPU 将安全地忽略它，其他将受益匪浅）。
@S.Jordan 不过，您可以提供已经是图像布局的finalLayout。如果您有一些高级需求（做复杂的引擎），它可能会很有用，在这些需求中，便利性\灵活性\可维护性胜过性能。但大多数时候（尤其是在教程阶段）最好坚持使用默认值（API 正在哄你做什么）——提供正确的finalLayout 意味着驱动程序可以如上所述进行优化，也意味着驱动程序更快地知道应用程序位的同步+转换要求（这也可能有帮助）。
我在考虑将总体布局用作占位符，直到使用屏障设置正确的布局。现在，根据您的评论，我发现当布局未知时，我可以在渲染过程中简单地设置 finalLayout=initialLayout，这可能会更有效。我应该提到我确实使用了一个大型引擎，该引擎目前不跟踪资源，以便让我在渲染通道开始时知道最终布局。
如果图像未绑定为输出附件，仅作为下一次绘制调用期间的输入采样器，我能否在渲染过程中使用屏障更改图像的布局？