可以使用管道屏障同步 vkQueuePresentKHR 吗？

如何解决可以使用管道屏障同步 vkQueuePresentKHR 吗？

vkQueuePresentKHR 获取队列参数的事实让我觉得它就像一个命令传递到队列执行。如果是这样，则可以使用源阶段为 VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT 且目标为 VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT 的管道屏障使其等待（直到写入要呈现的图像完成）。或者甚至可以通过图像屏障来缓解仅对图像的同步约束。

但是，在每个教程和书籍中，同步都是使用 semaphore 完成的，这一事实让我认为我的假设是错误的。如果是这样，为什么 vkQueuePresentKHR 需要队列参数？因为semaphore参数好像就够了：当有信号时，vkQueuePresentKHR可以根据图像索引参数和交换链句柄参数呈现图像。

解决方法

该规范有几个未解决的问题。值得注意的是，KhronosGroup/Vulkan-Docs#1308 正是您的问题。

与此同时，每个人通常都遵循这种语言：

演示文稿的处理与其他队列操作按问题顺序发生，但必须使用信号量来确保指定队列中的先前渲染和其他命令在演示文稿开始之前完成。

这意味着必须使用信号量。鉴于我们不是 110% 确定，这意味着应该使用信号量，直到我们知道任何更好的情况。

另一个半官方来源是 sync wiki，它使用信号量。

尽管这句话说了些什么，但我认为有理由相信，在 vkQueuePresent 之前使用其他使图像已经可见的同步也是允许的，例如围栏等待。

但仅管道壁垒可能还不够。演示文稿在队列系统之外：

然而，这组队列操作的范围不包括呈现引擎对图像的实际处理。

另外它没有VkPipelineStageFlagBit，而且vkQueuePresentKHR不包含在提交订单中，所以它不能在任何{{1}的同步范围内}.

令人困惑的部分是这个不幸的措辞：

在执行 vkCmdPipelineBarrier 之前可用的 pImageIndices 和 pSwapchains 成员引用的图像支持的任何写入内存都会自动对由表示引擎执行的读取访问。

我相信诀窍是“在执行 pPresentInfo 之前”。如上所述，vkQueuePresentKHR 不是提交顺序的一部分，因此您不知道在执行 vkQueuePresentKHR 之前内存是否通过管道屏障可用。

Presentation 是一个队列操作。这就是您将其提交到队列的原因。将执行图像呈现的队列。尤其是能够执行当前操作的队列。

至于如何同步...the specification is a bit ambiguous on this point。

信号量绝对可以工作；对此有一个特定的标注：

信号量对于使先前命令的结果可见：

任何写入内存支持由 pImageIndices 的 pSwapchains 和 pPresentInfo 成员引用的图像，在执行 vkQueuePresentKHR 之前可用，都是自动使呈现引擎执行的读取访问可见。图像的这种自动可见性操作发生在信号量信号操作之后，并且发生在呈现引擎访问图像之前。

虽然对信号量做了规定，但没有具体说明其他事项。特别是，如果您不等待信号量，则不清楚“发生 - 在信号量信号操作之后”是什么意思，因为没有发生这样的信号操作。

现在，vkQueuePresentKHR 的 API 清楚地表明您不需要提供信号量来等待：

waitSemaphoreCount 是发出当前请求之前要等待的信号量数。

数字可能为零。

可能会认为，作为队列操作，该队列上的所有先前同步仍会影响呈现。例如，如果您将交换链图像作为附件写入，则为外部子通道依赖项。它可能会......如果不是因为一个小问题。

看，同步最终是基于阶段之间的依赖关系。和演示文稿...没有舞台。因此，虽然您可以很好地理解外部依赖的来源，但尚不清楚 destination 哪个阶段会起作用。即使指定所有阶段标志也不一定有效。

所有阶段的集合中是否存在“非阶段”？

无论如何，最好只使用信号量。无论如何，您可能需要一个，所以就使用它。