vulkan - 无法与渲染并行获取和呈现？

Question

注意:我正在自学 Vulkan，对现代 OpenGL 知之甚少。

阅读 Vulkan 规范，我可以看到非常好的信号量，它允许命令缓冲区和交换链同步。这是我理解的一种简单(但我认为效率低下)的做事方式:

1. 使用 vkAcquireNextImageKHR 获取图像，向 sem_post_acq 发送信号
2. 构建命令缓冲区(或使用预构建的):
   • 从 VK_IMAGE_LAYOUT_UNDEFINED 转移图像的图像障碍
   • 渲染
   • 将图像转换为 VK_IMAGE_LAYOUT_PRESENT_SRC_KHR 的图像障碍
3. 提交到队列，在片段阶段等待 sem_post_acq 并发出 sem_pre_present 信号。
4. vkQueuePresentKHR 正在等待 sem_pre_present。

这里的问题是命令缓冲区中的图像屏障必须知道它们正在转换哪个图像，这意味着 vkAcquireNextImageKHR 必须在知道如何构建命令缓冲区(或哪个预建立命令缓冲区提交)。但是 vkAcquireNextImageKHR 可能会睡很多(因为演示引擎很忙，没有免费图像)。另一方面，命令缓冲区的提交本身是昂贵的，更重要的是，片段可以运行之前的所有阶段都不知道最终结果将渲染到哪个图像。

理论上，在我看来，像下面这样的方案将允许更高程度的并行性:

1. 构建命令缓冲区(或使用预构建的):
   • 从 VK_IMAGE_LAYOUT_UNDEFINED 转移图像的图像障碍
   • 渲染
   • 将图像转换为 VK_IMAGE_LAYOUT_PRESENT_SRC_KHR 的图像障碍
2. 提交到队列，在片段阶段等待 sem_post_acq 并发出 sem_pre_present 信号。
3. 使用 vkAcquireNextImageKHR 获取图像，向 sem_post_acq 发送信号
4. vkQueuePresentKHR 正在等待 sem_pre_present。

在我们等待 vkAcquireNextImageKHR 时，从理论上讲，这将允许管道一直执行到片段着色器。这不起作用的唯一原因是既不可能告诉命令缓冲区稍后将确定此图像(通过适当的同步)，也不可能向表示引擎询问特定图像。

---

我的第一个问题是:我的分析是否正确？如果是这样，这样的优化在 Vulkan 中根本不可能吗？为什么不呢？

---

我的第二个问题是:如果您可以告诉 vkAcquireNextImageKHR 您想要获取哪个特定图像并自行遍历它们，这不是更有意义吗？这样，您就可以提前知道您要请求哪个图像，并相应地构建和提交您的命令缓冲区。

Answer 1

就像 Nicol 所说的那样，您可以独立于要渲染到的图像来记录次要图像。

然而，您可以更进一步，预先记录所有 swpachain 图像的命令缓冲区，并从获取的图像中选择正确的提交。

这种类型的重用确实需要一些额外的考虑，因为所有使用的内存范围都被写入命令缓冲区。但在许多情况下，所需的渲染命令实际上不会将一帧帧更改为下一帧，只会使用一点点数据。

所以这样一个帧的顺序是:

vkAcquireNextImageKHR(vk.dev, vk.swap, 0, vk.acquire, VK_NULL_HANDLE, &vk.image_ind);
vkWaitForFences(vk.dev, 1, &vk.fences[vk.image_ind], true, ~0);

engine_update_render_data(vk.mapped_staging[vk.image_ind]);

VkSubmitInfo submit = build_submit(vk.acquire, vk.rend_cmd[vk.image_ind], vk.present);
vkQueueSubmit(vk.rend_queue, 1, &submit, vk.fences[vk.image_ind]);

VkPresentInfoKHR present = build_present(vk.present, vk.swap, vk.image_ind);
vkQueuePresentKHR(vk.queue, &present);

虽然这不允许条件渲染，但 gpu 通常速度足够快，可以让某些几何体在帧外渲染，而不会出现任何明显的延迟。因此，在玩家到达必须显示新几何体的加载区之前，您可以让这些命令缓冲区保持事件状态。