屏障和图像过渡答案

【问题标题】：Barrier and image transition屏障和图像过渡
【发布时间】：2016-11-03 22:09:49
【问题描述】：

我想知道为什么我们通常（来自 Vulkan 教程和 Sascha Willems 示例）管道顶部的屏障。

如果我像生产者和消费者一样推理（例如创建 mipmap），我在 src 和 dst 阶段都有“标志”“TRANSFER_BIT”。所以，如果我对 src 和 dst 使用相同的阶段，那么障碍应该立即发生，如果我使用 TOP_OF_PIPE 标志也是同样的情况？

我说的对吗？

【问题讨论】：

目前还不清楚 src 和 dst 具有相同的阶段与屏障执行的速度有什么关系。我不明白你对 Vulkan 管道障碍的理解是什么。
barrier中stageflags的目标主要是确保资源用户之间的执行依赖。
@NicolBolas krOoze 更详细地向我解释了我以前不了解的内容。简单来说，我不明白为什么 Sascha Willems 在生成 mipmap 时使用 TOP_OF_PIPE 进行布局转换。对我来说，“正确的方法”应该是使用 src = dst = TRANSFER_BIT ......也许我错过了一些关于“vkImageMemoryBarrier”中“掩码”的细节......

标签： vulkan

【解决方案1】：

我不确定我是否理解这个问题，但希望我能解释一下障碍。

src=TOP_OF_PIPE 或dst=BOTTOM_OF_PIPE 构成非阻塞屏障（实际上只是内存依赖的一半，没有执行依赖）。这就是你所说的“立即发生”的障碍吗？

dst=TOP_OF_PIPE 或 src=BOTTOM_OF_PIPE 应该是全阻塞屏障（至少我经常在示例和教程中看到它）。从规范中我不太清楚（特别是如果内存依赖也需要在那里），ALL_COMMANDS（或|ing 特定阶段）似乎是更好的替代品。

（顺便说一句，我用那个 API 设计写了关于 my peeve 的文章。）

一般而言，对于执行依赖，屏障的作用是：它们确保屏障之前记录的所有命令的srcStage 在屏障启动后记录的任何命令的dstStage 之前完成。
（上述特殊情况也应与该描述一致。）

所以，话虽如此，TOP_OF_PIPE 似乎不是TRANSFER 的合适替代品。它要么根本无法执行其预期功能，要么效率低下（基于上述描述）。

srcStage==dstStage 没有特殊含义。在这种情况下使用TRANSFER 意味着先前记录的命令的TRANSFER 阶段在屏障之后记录的命令的TRANSFER 阶段之前完成。

【讨论】：

那么，这样下去，为什么有些例子（比如 Sascha Willems 的例子）使用 TOP_OF_PIPE 而不是转移？我在图像内存屏障中有 src 和 dst 访问权限。那么是不是说，即使转账没有完成，被转账的那几个也是“可见”的呢？但是在这种情况下，Sascha给出的代码应该是错误的吧？还是我错过了什么？对于 mipmap 生成，您是否建议使用 src = dst = TRANSFER？
懒惰的实现（只是尝试一个通用的所有阻塞屏障，可以很容易地在任何地方重用）和惰性（许多早期的例子都是这样的。）。 @SashaWillems 有一个最早的例子和最完整的集合（我发誓那个人是一个军团）。如果您在许多教程中看到它，那是因为它们仍然从他那里汲取灵感。
好的，谢谢，所以他这样做只是为了“更具可读性”，但在“稳健的实现”中，我应该使用传输位？？
PS 取决于你所说的 mip-map 生成是什么意思。如果常见的 for(){cmdBlit} 事情那么 src = dst = TRANSFER 似乎是个好主意。
@AntoineMorrier 是的，它是一个可读性、复杂的引擎灵活性和编码工作与低级和性能的东西。您可以只制作一个src=dst=ALL_COMMANDS（AIS 很多人使用我不喜欢src=BOTTOM_OF_PIPE + dst=TOP_OF_PIPE 来实现相同的效果）障碍并将其扔到任何地方，而不是根据（潜在）性能成本的情况量身定制的障碍。代码错误也总是可能的（如果不提供您所谈论的确切代码，很难判断）