哪些阻止了 Vulkan 功能？

Question

在 Vulkan 中，建议将 API 调用分解为单独的线程以获得更好的吞吐量。我不确定哪一类调用是计算成本高的调用，会导致线程阻塞，因此应该异步使用。

在我看来，这些是可能需要很长时间才能执行的潜在调用/调用系列。

• vkAcquireImageKHR()
• vkQueueSubmit()
• vkQueuePresentKHR()
• memcpy 进入映射内存
• vkBegin/EndCommandBuffer
• vkCmd* 调用绘图和计算

但是，我对它们的思考越多，似乎打电话给大多数人的费用就越便宜。我会解释我的理性，这可能是有缺陷的。

vkAcquireImageKHR()

如果您选择超时，这可能会阻塞。但是，经过充分优化的应用程序很可能会在超时为 0 的情况下调用此函数，如果图像尚不可用，则仅执行其他工作。所以，这个功能可以即时完成。如果应用程序足够智能，则无需等待。

vkQueueSubmit()

这个函数需要一个栅栏，当 GPU 完成执行命令缓冲区时会发出信号。因此，它实际上并没有在 GPU 执行工作时等待。我假设这个函数是开始将命令缓冲区数据物理移动到 GPU 的函数，但我假设它告诉硬件从某个内存位置读取，然后函数尽快返回。因此，当命令缓冲区被发送到 GPU 时，它不会等待。

vkQueuePresentKHR()

向 GPU 发送信号以将一些图像发送到窗口/监视器。它不必等待太多，不是吗？

memcpy 进入映射内存

这可能很慢。

vkCmd* 调用

这一系列电话是我最不确定的。当我读到线程和 Vulkan 时，通常是这些调用被放到线程上。但是，这些电话到底在做什么？他们是否正在构建一些操作码缓冲区，由一些整数和指针组成，以发送到 GPU？如果是这样，那应该是非常快的。实际工作是执行这些操作码所描述的操作。

Answer 1

定义“块”。“阻塞”的传统定义是等待一些内部同步，从而花费比操作严格所需的时间更长的时间。做 amemcpy不做任何同步；它只是复制数据。

所以你似乎并不关心“阻塞”；你只是在谈论什么操作是昂贵的。

vkQueueSubmit不阻塞。但这并不意味着它不贵。它不是“告诉[ing] 硬件从某个内存位置读取”只是看看它的接口。它不需要单个命令缓冲区；它需要任意数量的它们，它们被分组到批处理中，每个批处理在执行前等待信号量，执行后发出信号量，整个操作发出一个栅栏信号。

您不能合理地期望这种事情的实现仅仅复制一些指针。

这甚至没有涉及不同类型的命令缓冲区的问题。提交SIMULTANEOUS_USE命令缓冲区可能需要为其缓冲数据创建临时副本，以便不同的批次可以包含相同的命令缓冲区。

现在很明显，vkQueueSubmit它将在它提交的任何工作实际执行之前很好地返回。但是不要错误地认为可以免费将工作发送到 GPU。Vulkan 规范在注释中留出一些时间，直接告诉您不要比您能逃脱的更频繁地调用该函数：

提交可能是一项高开销操作，应用程序应尝试将批处理工作合并到尽可能少的调用中vkQueueSubmit。

在提交生成所呈现图像的 CB 的同一线程上呈现的原因并不是因为这些操作中的任何一个都必然很慢。这是为了简单的实用主义；这三个操作（获取、提交、呈现）必须按顺序发生。确保这一点的最简单和最简单的方法是在同一线程上执行它们。

您不能提交渲染到交换链图像的作品，直到您获得它。因此，要么在同一线程上执行此操作，要么必须有一些线程间通信管道来告诉等待构建主 CB 的线程获取的图像是什么。这两个过程不能重叠。

与获取不同，present 是一个队列操作。而且两者vkQueueSubmit并vkQueuePresent要求获得他们的VkQueue参数必须是“外部synchoronized”。这当然意味着您不能VkQueue在同一时间从不同线程同时调用它们。因此，如果您尝试并行执行这些操作，则需要一个互斥锁或其他东西来同步 CPU 对VkQueue.

而如果您在同一线程上执行它们，则没有必要。

此外，为了呈现图像，您必须提供一个当前将等待的信号量。该信号量将由为图像生成数据的批处理发出信号。Vulkan 需要订购信号量信号/等待对；您不能执行等待信号量的队列操作，直到发出信号量的操作已提交。因此，要么按顺序在同一线程上执行此操作，要么使用某个线程间通信管道来告诉正在等待呈现图像的线程已发出呈现给它的提交操作。

那么将这些操作拆分到不同的线程上会得到什么？它们必须按顺序发生，因此您不妨以现有的最简单方式按顺序执行它们：在同一线程上。

虽然时间线信号量现在允许您在提交增加信号量计数器的工作之前调用当前函数，但您仍然不能在单独的线程上调用它们（没有同步），因为它们影响同一个队列。因此，您也可以在同一线程上发布它们（尽管不一定按获取、提交、呈现顺序）。

最终，尚不清楚这项练习的意义是什么。是的，个人vkCmd*通话会很快。所以呢？在真实场景中，您将每帧调用这些函数数千次。将它们均匀分布在 4 个内核上可为您节省约 4 倍的性能。