Layout Vulkan：带有隐式布局转换的附件同步

我已经阅读了谷歌给我的关于这个话题的几乎所有内容，并没有能够得出令人满意的结论。这基本上是这个问题的后续问题：

假设我有一个颜色附件，它在一个渲染过程中写入，在第二个渲染过程中从中采样。让两个渲染过程中只有一个子过程。处理布局转换和相关性的一种方法是在两个渲染过程之间添加屏障，这会将布局从VK_图像_布局_颜色_附件_最优更改为VK_图像_布局_着色器_只读_最优

但Vulkan也提供了隐式布局转换（vkAttachmentDescription、initialLayout和finalLayout）。我想使用它们有一个性能优势，所以让我们试着摆脱障碍。我们在vkAttachmentDescription结构中设置initialLayout和finalLayout字段，并移除障碍。问题是，我们失去了屏障提供的同步，因此我们需要通过其他方式恢复同步。这就是困惑的起点，引出了我的问题：

1） 在两个渲染过程之间同步附件的建议方法是什么？显然，我可以简单地重新添加屏障，而不更改布局，但这是否会违背整个练习的目的，即通过使用隐式布局转换和消除屏障来获得更好的性能？或者我应该从渲染过程1的单个子过程添加子过程依赖项到VK_subpass_EXTERNAL吗？在使用VK_子类_外部性能方面是否有任何警告

2） 向后同步附件怎么样？应用程序负责将附件转换到正确的初始布局，这显然可以通过屏障完成。是否可以替换此屏障以获得性能优势？我能想到的唯一方法是，使用渲染过程1的单个子过程外部的VK_SUBPASS_的子过程依赖项来执行依赖项部分，并使用“快速”屏障（不同步的屏障），该屏障只会更改布局。这有意义吗？那个屏障看起来怎么样？或者在这种情况下，“完全”障碍不可避免吗

我的问题的简短版本很简单：其他人如何将附件同步与隐式布局转换结合起来

我的问题的简短版本很简单：其他人如何将附件同步与隐式布局转换结合起来

渲染过程依赖关系是您要寻找的。如果有两个渲染过程，则需要使用提到的

VK_SUBPASS_EXTERNAL

值

应用程序负责将附件转换到正确的初始布局，这显然可以通过屏障完成。是否可以替换此屏障以获得性能优势

---

无论您如何执行布局转换，这都无关紧要。您有责任将图像的布局转换为指定为初始布局的布局。但我认为最好的方法是再次使用渲染过程提供的隐式布局转换。如果您已经在使用它们，应该可以这样设置它们：第一个渲染过程将图像转换为与第二个渲染过程的初始布局相同的布局，第二个渲染过程的最终布局与第一个渲染过程的初始布局相同。

一般来说，当Vulkan或类似的低级API为您提供了多种可以实现您想要的功能的工具时，您应该优先选择能够解决您的问题的最具体的工具（无需从根本上重新设计代码或从根本上影响您的设计）

在本例中，有两个选项：屏障或渲染过程机制（子过程依赖项和布局转换）。障碍对任何事物都起作用；他们不在乎图像来自何处，用于何处，或者它将要去哪里。渲染过程机制仅适用于渲染过程中发生的内容，主要处理附加到渲染过程的图像（隐式布局转换仅适用于附件）

渲染过程机制更为具体，因此如果这些工具满足您的需要，您应该更愿意使用它们

---

这也是为什么，如果您有两个“独立”的渲染操作可以在同一个渲染过程中进行（如果您正在以一种可以在输入附件的限制范围内进行的方式从附件中读取），那么您应该将它们放在同一个渲染过程中。

谢谢，这几乎完全回答了我的问题。如果附件在上一个渲染过程中没有用作附件，那么2）的答案是什么？这不会太多地改变情况。仍然需要将图像转换为适当的布局（与第二个渲染过程的初始布局相同）。如果未将其用作渲染过程中的附件，则无法利用隐式布局转换，因此需要使用屏障。几乎达到了：假设我要将图像从渲染过程1中读取的着色器转换为渲染过程2中写入的附件。有两种实现转换和同步的方法：A）两个渲染过程之间的完全屏障B）与渲染过程2中的子过程依赖项同步（从VK_子过程_外部到子过程），以及在两个渲染过程之间使用无同步屏障（管道顶部_->管道底部_）转换布局。A） 总是正确的，我问B）是否也正确，从性能的角度看是否有潜在的好处。@S.Jordan我认为建议做所有事情，正如Nicol Bolas所说，只使用渲染过程提供的机制。所以我认为应该是C）与子类依赖项同步（我认为应该在两个渲染过程中定义适当的依赖项，但是应该有人确认这一点）和t