在 Vulkan(或任何其他现代图形 API)中,栅栏应该按队列提交还是按帧等待?
In Vulkan (or any other modern graphics API), should fences be waited per queue submission or per frame?
我正在尝试以渲染始终渲染到纹理的方式设置我的渲染器,然后我只呈现我喜欢的任何纹理,只要它的格式与交换链兼容即可。这意味着,我需要处理一个渲染场景的图形队列(我还没有计算),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队列先于第二个队列执行?
整个组织方案似乎很可疑。
即使忽略 Vulkan 规范不要求 GPU 为所有这些事情提供单独队列这一事实,您仍在异步执行中分散一系列操作,尽管这些操作 固有顺序。在渲染图像之前不能从图像复制到交换链,并且在复制完成之前不能呈现交换链图像。
所以这些东西放到自己的队列里基本没有什么优势。只需在同一个队列中执行所有这些操作(一个提交和一个 vkQueuePresentKHR
),在操作之间使用适当的执行和内存依赖性。这意味着只有一件事需要等待:单次提交。
另外,提交操作真的很昂贵;如果提交是在可以同时工作的不同 CPU 线程上完成的,那么进行两次提交而不是一次包含两部分工作的提交是一件好事。但是二进制信号量阻止了它的工作。在提交 signals semaphore A 之前,您不能提交等待信号量 A 的批处理。这意味着批处理信号必须在同一提交命令中更早,或者必须已经在先前的提交命令中提交。这意味着如果你将这些提交放在不同的线程上,你必须使用互斥锁或其他东西来确保信号提交 happens-before 等待提交。1
所以您不会得到队列提交操作的任何异步执行。所以 CPU 和 GPU 都不会异步执行任何这些。
1: 时间轴信号量没有这个问题
关于你的技术问题的细节,如果操作A依赖于操作B,并且你与A同步,你也与B同步。由于你的传输操作是等待来自图形队列的信号,等待传输操作也将等待该信号之前的图形命令。
我正在尝试以渲染始终渲染到纹理的方式设置我的渲染器,然后我只呈现我喜欢的任何纹理,只要它的格式与交换链兼容即可。这意味着,我需要处理一个渲染场景的图形队列(我还没有计算),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队列先于第二个队列执行?
整个组织方案似乎很可疑。
即使忽略 Vulkan 规范不要求 GPU 为所有这些事情提供单独队列这一事实,您仍在异步执行中分散一系列操作,尽管这些操作 固有顺序。在渲染图像之前不能从图像复制到交换链,并且在复制完成之前不能呈现交换链图像。
所以这些东西放到自己的队列里基本没有什么优势。只需在同一个队列中执行所有这些操作(一个提交和一个 vkQueuePresentKHR
),在操作之间使用适当的执行和内存依赖性。这意味着只有一件事需要等待:单次提交。
另外,提交操作真的很昂贵;如果提交是在可以同时工作的不同 CPU 线程上完成的,那么进行两次提交而不是一次包含两部分工作的提交是一件好事。但是二进制信号量阻止了它的工作。在提交 signals semaphore A 之前,您不能提交等待信号量 A 的批处理。这意味着批处理信号必须在同一提交命令中更早,或者必须已经在先前的提交命令中提交。这意味着如果你将这些提交放在不同的线程上,你必须使用互斥锁或其他东西来确保信号提交 happens-before 等待提交。1
所以您不会得到队列提交操作的任何异步执行。所以 CPU 和 GPU 都不会异步执行任何这些。
1: 时间轴信号量没有这个问题
关于你的技术问题的细节,如果操作A依赖于操作B,并且你与A同步,你也与B同步。由于你的传输操作是等待来自图形队列的信号,等待传输操作也将等待该信号之前的图形命令。