buffer - vulkan push 常量与统一缓冲区更新

Question

所以我现在正在阅读 vulkan 的书，并且遇到了有关推送常量和 ubo 更新的问题。

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

另一方面，当我使用 push constant 时，就没有这样的问题。虽然它很小(比如 256 字节大)。

到目前为止一切顺利。

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

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

谢谢。

Answer 1

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

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

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

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

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

目前您似乎正在预录。对于这种数据，我根本不会为推送常量而烦恼。在您更加熟悉 vulkan 之前，我也不会关注这些类型的问题，因为在 vulkan 中进行优化很容易陷入困境，优化策略远没有 CPU 空间那么统一。