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

Question

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

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

// 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 的批次。这意味着批次信号必须在同一提交命令中较早出现，或者必须已在之前的提交命令中提交。这意味着如果您将这些提交放在不同的线程上，则必须使用互斥体或其他东西来确保信号提交发生在等待提交之前。¹

因此，您不会获得任何队列提交操作的异步执行。因此 CPU 和 GPU 都不会异步执行这些操作。

¹：时间轴信号量没有这个问题。

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