所以我现在正在读 vulkan 书，遇到了关于推送 Constant 和 ubo 更新的问题。
在我设置所有管道和描述符之后。基本上我只需要将缓冲区复制到 UBO 缓冲区（例如 memcpy），然后我就完成了。基本上我可以理解整个管道需要等待这个“缓冲区”准备好然后更改其内容的问题。所以会很慢。
另一方面，当我使用push Constant时，就不存在这样的问题。虽然它很小（比如 256 字节大）。
到目前为止，一切都很好。
然而，再一想，我发现如果我更新UBO，我不需要更改命令缓冲区，或重新记录它，我可以提交旧的CB，因为它仍然是相同的。然后如果我想使用 Push Constant 进行更新，我必须重置 CB 并重新记录然后提交。
那么这不会成为一个问题吗？如何确定哪个更快？
谢谢。
很多人对这个问题感到困惑，因为Vulkan 教程会预先记录命令，而Vulkan 指南会在每一帧重新记录命令。
当人们说对每帧更改数据（例如变换矩阵和时间数据）使用推送常量时，隐含的假设是您正在每帧记录命令缓冲区。推送常量本质上是在提交时与其余命令搭便车，这也是它们避免同步和缓存刷新操作的方式。
现在，在很多情况下，重新记录命令缓冲区可能比重新使用更容易，而且成本也不会更高。事实上，当情况发生变化时重新使用命令缓冲区可能会非常难以管理。命令缓冲区旨在快速记录。尽管如此，Vulkan 教程还是预先记录了所有内容，这也是一种有效的方法，尽管可能更难以大规模维护。
在创建本教程时，Vulkan 教程本质上是唯一可用于以结构化方式学习 vulkan 的资源之一。尽管命令缓冲区的记录速度很快，但预记录命令缓冲区甚至可以消除更多的 CPU 开销，并体现了 Vulkan 的“不再受到绘制调用限制”的口号，以消除图形应用程序中的 CPU 开销。
至于速度比较，您必须进行基准测试，但出于“速度”原因，我不一定会选择其中之一。如果您预先录制，您不想仅仅为了利用推送常量而重新定向整个渲染架构。如果您不预先记录，则没有理由不使用推送常量，它们只是更容易处理。
目前看来您正在预录制。对于这种数据，我根本不会为推送常量而烦恼。在你更加熟悉 vulkan 之前，我也不会关注这类问题，因为 vulkan 的优化很容易陷入困境，优化策略远不如 CPU 空间那么统一。
| 归档时间： |
|
| 查看次数： |
2157 次 |
| 最近记录： |