在 Vulkan（或任何其他现代图形 API）中，是否应该在每个队列提交或每帧等待栅栏？

Question

我正在尝试以渲染始终渲染为纹理的方式设置我的渲染器，然后我只呈现我喜欢的任何纹理，只要它的格式与交换链兼容。这意味着，我需要处理一个渲染场景、ui 等的图形队列（我还没有计算）；一个将渲染图像复制到交换链中的传输队列；和一个用于呈现交换链的呈现队列。这是我目前正在尝试解决的用例，但随着渲染器的成熟，我将拥有更多这样的用例（例如计算队列）。

这是我想要实现的伪代码。我也在这里添加了一些我自己的假设：

// wait for fences per frame
waitForFences(fences[currentFrame]);
resetFences(fences[currentFrame]);

// 1. Rendering (queue = Graphics)
commandBuffer.begin();
renderEverything();
commandBuffer.end();

QueueSubmitInfo renderSubmit{};
renderSubmit.commandBuffer = commandBuffer;

// Nothing to wait for
renderSubmit.waitSemaphores = nullptr;

// Signal that rendering is complete
renderSubmit.signalSemaphores = { renderSemaphores[currentFrame] };

// Do not signal the fence yet
queueSubmit(renderSubmit, nullptr);

// 2. Transferring to swapchain (queue = Transfer)

// acquire the image that we want to copy into
// and signal that it is available
swapchain.acquireNextImage(imageAvailableSemaphore[currentFrame]);

commandBuffer.begin();
copyTexture(textureToPresent, swapchain.getAvailableImage());
commandBuffer.end();

QueueSubmitInfo transferSubmit{};
transferSubmit.commandBuffer = commandBuffer;

// Wait for swapchain image to be available
// and rendering to be complete
transferSubmit.waitSemaphores = { renderSemaphores[currentFrame], imageAvailableSemaphore[currentFrame] };

// Signal another semaphore that swapchain
// is ready to be used
transferSubmit.signalSemaphores = { readyForPresenting[currentFrame] };

// Now, signal the fence since this is the end of frame
queueSubmit(transferSubmit, fences[currentFrame]);

// 3. Presenting (queue = Present)
PresentQueueSubmitInfo presentSubmit{};

// Wait until the swapchain is ready to be presented
// Basically, waits until the image is copied to swapchain
presentSubmit.waitSemaphores = { readyForPresenting[currentFrame] };

presentQueueSubmit(presentSubmit);

我的理解是需要栅栏来确保 CPU 等到 GPU 完成将上一个命令缓冲区提交到队列。

在处理多个队列的时候，让CPU只等待帧，用信号量同步不同的队列就够了吗（上面的伪代码就是基于这个）？还是每个队列应该分别等待栅栏？

进入技术细节，如果两个命令缓冲区被提交到同一个队列而没有任何信号量会发生什么？伪代码：

// first submissions
commandBufferOne.begin();
doSomething();
commandBufferOne.end();

SubmitInfo firstSubmit{};
firstSubmit.commandBuffer = commandBufferOne;
queueSubmit(firstSubmit, nullptr);

// second submission
commandBufferTwo.begin();
doSomethingElse();
commandBufferTwo.end();

SubmitInfo secondSubmit{};
secondSubmit.commandBuffer = commandBufferOne;
queueSubmit(secondSubmit, nullptr);

第二次提交会覆盖第一个，还是第一个 FIFO 队列会在第二个之前执行，因为它是第一次提交的？

Answer 1

这整个组织计划似乎是可疑的。

即使忽略 Vulkan 规范不要求 GPU 为所有这些事情提供单独的队列这一事实，您仍在异步执行中传播一系列操作，尽管事实上这些操作是固有顺序.在图像被渲染之前，您无法从图像复制到交换链，并且在复制完成之前，您无法呈现交换链图像。

所以把这些东西放到自己的队列里基本上没有什么好处。只需在同一个队列中执行所有这些操作（一个提交和一个vkQueuePresentKHR），在操作之间使用适当的执行和内存依赖关系。这意味着只有一件事需要等待：单次提交。

另外，提交操作真的很昂贵；如果提交是在可以同时工作的不同 CPU 线程上完成的，那么做两个提交而不是一个包含两个工作的提交只是一件好事。但是二进制信号量阻止了它的工作。在您提交一个等待信号量 A 的批次之前，您不能提交一个等待信号量 A 的批次。信号信号量 A。这意味着批处理信号必须在同一个提交命令中更早，或者必须在之前的提交命令中提交。这意味着如果您将这些提交放在不同的线程上，则必须使用互斥锁或其他东西来确保信号提交发生在等待提交之前。¹

所以你不会得到队列提交操作的任何异步执行。所以 CPU 和 GPU 都不会异步执行任何这些。

¹: 时间线信号量没有这个问题。

---

至于您的技术问题的细节，如果操作A依赖于操作B，并且您与A同步，您也与B同步。由于您的传输操作是等待来自图形队列的信号，因此等待传输操作还将等待该信号之前的图形命令。