在 Vulkan 中重新绑定图形管道是否保证无操作? [英] Is rebinding a graphics pipeline in Vulkan a guaranteed no-op?

问题描述

在将要渲染的每个对象转换为辅助命令缓冲区并且这些命令缓冲区中的每一个最初绑定一个图形管道的简化场景中:是否有保证的无操作来绑定之前立即绑定的管道?或者二级命令缓冲区的执行顺序根本没有保证?

In the simplified scenario where each object to be rendered is translated into a secondary command buffer and each of those command buffers bind a graphics pipeline initially: is a guaranteed no-op to bind the pipeline that was immediately bound before? Or the order of execution of the secondary command buffers is not guaranteed at all?

推荐答案

是绑定之前绑定的管道的保证无操作吗?

is a guaranteed no-op to bind the pipeline that was immediately bound before?

没有.事实上，在您概述的情况下，您应该准确地假设相反.为什么?

No. In fact, in the case you're outlining, you should assume precisely the opposite. Why?

由于您的每个 CB 都与其他 CB 隔离，因此 vkCmdBindPipeline 函数无法知道事先绑定了什么.请记住:已开始记录的命令缓冲区的状态是未定义.这意味着命令缓冲区构建代码不能对您未在此 CB 中设置的任何状态做出任何假设.

Since each of your CBs is isolated from the others, the vkCmdBindPipeline function has no way to know what was bound beforehand. Remember: the state of a command buffer that has started recording is undefined. Which means that the command buffer building code cannot make any assumptions about any state which you did not set within this CB.

为了让驱动程序实现您正在谈论的优化，它必须在 vkCmdExecuteCommands 时间内省每个辅助命令缓冲区并开始删除跨 CB 复制的任何内容边界.

In order for the driver to implement the optimization you're talking about, it would have to, at vkCmdExecuteCommands time, introspect into each secondary command buffer and start ripping out anything that is duplicated across CB boundaries.

如果 vkCmdExecuteCommands 必须将辅助 CB 中的所有命令复制到主要命令中，那么 可能 是可行的.但这仅适用于在硬件级别不存在辅助 CB，因此必须通过将其命令复制到主 CB 来实现的系统.但即使在这种情况下，与简单地将一些令牌复制到主 CB 的存储中相比，实施此类剔除也会使命令的执行时间更长.

That might be viable if vkCmdExecuteCommands has to copy all of the commands out of secondary CBs into primary ones. But that would only be reasonable for systems where secondary CBs don't exist at a hardware level and thus have to be implemented by copying their commands into the primary CB. But even in this case, implementing such culling would make the command take longer to execute compared to simply copying some tokens into the primary CB's storage.

在处理低级 API 时，不要假设驱动程序将使用其直接权限之外的信息来优化您的代码.特别是当您拥有自己进行优化的工具时.

When dealing with a low-level API, do not assume that the driver is going to use information outside of its immediate purview to optimize your code. Especially when you have the tools for doing that optimization yourself.

这是(又一个)你不应该给每个单独的对象自己的 CB 的原因.

This is (yet another) a reason why you should not give each individual object its own CB.

或者二级命令缓冲区的执行顺序根本没有保证?

Or the order of execution of the secondary command buffers is not guaranteed at all?

命令的执行顺序不会因为它们在 CB 中的存在而改变.但是，这些命令使用的状态的明确定义的性质受到影响.

The order of execution of commands is unchanged by their presence in CBs. However, the well-defined nature of the state these commands use is affected.

在次要 CB 继承的状态之外，每个次要 CB 的状态都开始未定义.这就是为什么您必须为每个管道绑定一个管道.如果先前发出的状态在包含该命令的 CB 内(或继承状态)，则依赖于先前发出的状态的命令才具有明确定义的行为.

Outside of state inherited by secondary CBs, every secondary CB's state begins undefined. That's why you have to bind a pipeline for each one. Commands that rely on previously issued state only have well-defined behavior if that previously issued state is within the CB containing that command (or is inherited state).

这篇关于在 Vulkan 中重新绑定图形管道是否保证无操作?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！