vulkan pushConstant 与统一缓冲区更新

所以我现在正在阅读 vulkan 的书并且遇到了关于 push Constant 和 ubo 更新的问题。

在我设置所有管道和描述符之后。基本上我只需要将缓冲区复制到 UBO 缓冲区，例如 memcpy，然后我就完成了。基本上我可以理解关于整个管道的问题需要等待这个“缓冲区”准备好然后改变它的内容。所以会很慢。

另一方面，当我使用推送常量时，没有这样的问题。虽然它很小（比如 256 字节大）。

到目前为止一切顺利。

但是，转念一想，我发现如果我更新UBO，我不需要更改命令缓冲区，或者重新记录它，我可以提交旧的CB，因为它仍然是一样的。然后如果我想使用Push Constant更新，我必须重置CB并重新记录然后提交。

所以这不会成为问题吗？如何确定哪个更快？

谢谢。

很多人对这个问题感到困惑，因为 Vulkan Tutorial 预记录命令和 Vulkan Guide 每帧重新记录命令。

当人们说要对每帧更改数据（如变换矩阵和时间数据）使用推送常量时，隐含的假设是您正在记录每帧的命令缓冲区。推送常量本质上是在提交时与其余命令搭便车，这也是它们避免同步和缓存刷新操作的方式。

现在，在很多情况下，重新记录命令缓冲区会更容易并且不会比重用成本高很多。事实上，当事情发生变化时重新使用命令缓冲区可能是一个真正的管理痛苦。命令缓冲区旨在快速记录。尽管如此，Vulkan 教程还是预先记录了所有内容，这也是一种有效的方法，但可能难以大规模维护。

在创建本教程时，Vulkan 教程基本上是唯一的资源之一，可用于以结构化的方式学习 vulkan。尽管命令缓冲区可以快速记录，但预记录命令缓冲区可以消除更多的 CPU 开销，并体现了 Vulkan 的“不再限制绘制调用”的口号，以消除图形应用程序中的 CPU 开销。

至于速度比较，您必须进行基准测试，但出于“速度”原因，我不一定会选择其中之一。如果您预先录制，您不想仅仅为了利用推送常量而重新定位整个渲染架构。如果您不预先记录，就没有理由不使用推送常量，它们只是更容易处理。

目前您似乎正在预先录制。对于这种数据，我根本不会理会推送常量。在您更熟悉 vulkan 之前，我也不会关注这些类型的问题，因为在 vulkan 中进行优化很容易陷入杂草中，优化策略远不如 CPU 空间中的统一。