【问题标题】:Creating multiple command pools per thread in Vulkan在 Vulkan 中为每个线程创建多个命令池
【发布时间】:2020-07-12 15:18:05
【问题描述】:

我正在尝试使用 Vulkan 设置多线程渲染器,但我对命令池有疑问。

https://on-demand.gputechconf.com/siggraph/2016/video/sig1625-tristan-lorach-vulkan-nvidia-essentials.mp4 在 13 分钟时,他们讨论了如何为每个 FRAME 创建 1 个命令池并在环形缓冲区中循环它们。

为什么要为每个线程分配 3 个命令池(一个用于 3 帧环形缓冲区中的每一帧),而不是每个线程只有一个命令池并从中分配 3 个命令缓冲区?

【问题讨论】:

    标签: c++ multithreading vulkan


    【解决方案1】:

    我认为这里的前提是vkResetCommandPool 比重置单个命令缓冲区更好。这还需要VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT 标志,其存在是规范本身的一点提示,即重置单个 cmdbuffers 的能力可能不是免费的。

    实际上演讲者是这么说的,如果您不只是阅读幻灯片,而是获得完整的演示文稿。

    【讨论】:

      【解决方案2】:

      这基本上是关于限制您必须执行多少同步和状态跟踪。如果每个线程每帧有一个命令池,那么您只需要跟踪单个事件以完成,然后重置整个命令池,无论您在其中为该帧创建了多少命令缓冲区。

      从引擎的角度来看,这对于您不打算多次重复使用的命令缓冲区非常有用 - 它们会变成无状态的触发并忘记实体,您只需要持续跟踪池即可。

      具体的权衡将因应用程序和驱动程序而异,因此 YMMV 以最有效的方式来衡量。

      【讨论】:

      • 我明白了,我想 '3' 是一个任意数字 - 如果帧需要更多时间才能完成,我可能需要更大的环形缓冲区
      • 您不希望交换链中的帧队列太深 - 从用户输入到屏幕上显示的内容的延迟变得太高。通常 2 或 3 个就可以了。 2 可能会导致垂直同步锁定问题,而 3 可以避免,但超过三重缓冲并没有真正的性能优势,它只会导致延迟问题。
      • 哦,我明白了,所以环形缓冲区中的命令池数量应该与交换链中的缓冲区数量相匹配?
      • 我不这么认为。交换链中的图像数量可能因不同的硬件供应商甚至驱动程序版本而异——即使创建参数相同。您指定所需的最小图像数量,但驱动程序可能会给您更多。因此,将环形缓冲区的大小与交换链图像的数量相匹配并不是最好的主意。看看这里:software.intel.com/en-us/articles/…
      猜你喜欢
      • 2023-02-11
      • 2014-12-10
      • 1970-01-01
      • 2023-04-04
      • 1970-01-01
      • 2020-01-06
      • 1970-01-01
      • 1970-01-01
      • 2012-09-03
      相关资源
      最近更新 更多