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

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

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

---

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