vulkan - 重置命令缓冲区是否比设置统一缓冲区更快？

Question

我正在尝试学习 Vulkan(主要来自 vulkan-tutorial.com)，因为我编写了一个混合图形/计算应用程序(我需要渲染一个深度缓冲区并对其执行一些计算，没有显示)。我几乎要渲染我的第一个(深度)图像，我需要做的就是弄清楚如何传递单个 vec4作为我的顶点着色器的唯一参数(除了位置属性)。

我读到的所有地方都说推送常量比制服快，所以它们似乎是我的参数的明显选择，但似乎我需要在每个渲染图像处重置命令缓冲区，以便使用 vkCmdPushConstants() 更改我的推送常量，而使用制服时，我可以保持命令缓冲区固定，并在使用 vkQueueSubmit() 提交渲染任务之前简单地更新映射的内存区域(如果不连贯，则刷新) .

重写整个命令缓冲区真的比映射内存写入快吗？或者说推送参数更快的人假设命令缓冲区将在每个渲染图像上重建，所以大部分成本已经支付了？

最后，我可以更新另一个命令缓冲区中的推送常量，更小，之前提交并与另一个命令缓冲区同步信号量？ (我猜不是，但我不清楚常量推送的有效时间，也不清楚管道保持绑定(bind)的时间。)如果可能，这是一个好方法吗？

编辑:不，那是不可能的，刚刚找到 here那:

Each command buffer manages state independently of other command buffers.

和

When a command buffer begins recording, all state in that command buffer is undefined.

因此我的问题仍然存在。

Answer 1

Is rewriting the whole command buffer really faster than a mapped memory write?

那是个错误的问题。您没有考虑修改内存以使 GPU 可以使用它实际需要什么。

好的，所以你有这个命令缓冲区，可以从一些内存中读取制服。并且您想在两个单独的框架中使用它。但是你想改变帧之间的内存。

好吧，在第一帧完成读取之前，您无法写入该内存。所以你需要 CB 在最后一次读取制服后设置一个事件。在为该帧提交 CB 之后，您需要在 CPU 上等待该事件，然后才能写入数据(更不用说提交下一帧的数据了)。

这就是 CPU/GPU 同步。对于 GPU 性能或 CPU 性能来说，这并不好。 GPU 可能会停止工作，因为 CPU 必须进行此类同步，而 CPU 可能只是坐在那里无所事事。

重建大多数命令缓冲区是 Vulkan 应用程序的典型工作方式。