vulkan - 为什么有些命令只能在渲染过程之外记录？

Question

我不知道这是API功能(我几乎可以肯定不是)还是GPU细节，但是为什么例如vkCmdWaitEvents可以记录在渲染过程的内部和外部，而vkCmdResetEvent却只能记录在外部？其他命令也一样。

Answer 1

特别是在事件设置方面，他们对渲染过程模型与基于图块的渲染器之间的交互方式产生了极大的破坏。

回想the whole point of the complexity of the render pass model is to service the needs of tile-based renderers (TBRs).当TBR遇到一系列复杂的子 channel 时，它想要执行的方式如下。

它为所有子 channel 的所有渲染命令一次完成所有顶点处理阶段，并将结果顶点数据存储在缓冲区中以备后用。然后，对于每个图块，它对与该图块的构建有关的图元上的每个子遍执行光栅化阶段。

请注意，这是理想情况；特定的事情会使它在不同程度上失败，但是即使那样，它也可能成批失败，在这种情况下，您可以执行渲染过程的多个子过程，如下所示。

假设您要在子 channel 中间设置一个事件。好吧...什么时候真正发生？请记住，在所有前面的命令完成之后，set-event命令实际上会设置事件。在TBR中，如果一切都按上述步骤进行，什么时候设置？理想情况下，整个渲染过程的所有顶点处理都应该在任何光栅化之前进行，因此设置事件必须在顶点处理完成后进行。并且所有栅格化处理都是在逐个图块的基础上进行的，无论哪个基元与该图块重叠都进行处理。由于渲染过程是零散的，因此很难知道单个渲染命令何时完成。

因此，只有在整个renderpass完成之后，才可以进行set-event调用。这显然不是很有用。

另一种方法是发出ckCmdSetEvent调用，从根本上重塑实现如何构建整个渲染过程的方式。将子 channel 分解为事件之前发生的事件和事件之后发生的事件。

但是VkRenderPass如此大而复杂的原因，VkPipeline不得不引用渲染过程的特定子 channel 的原因，以及渲染过程中的vkCmdPipelineBarrier要求您指定子过程自相关性的原因是， TBR实现可以预先知道何时何地必须打破理想的TBR呈现方案。有一个功能可以在没有事先警告的情况下引入这种分解，从而违背了这个想法。

此外，Vulkan的设计方式是，如果必须以非常低效的方式实现某些事情，那么要么直接做不到，要么API确实使它看起来效率很低。无法在TBR硬件上的渲染过程中有效地实现vkCmd(Re)SetEvent，因此您不能在此期间进行。

请注意vkCmdWaitEvents不会出现此问题，因为系统知道等待正在等待渲染 channel 之外的内容。因此，这只是一个特定的阶段，必须等待事件完成。如果在等待阶段是一个顶点阶段，那么在该命令的处理开始时设置等待就足够容易了。如果是分段阶段，则只需在所有光栅化处理的开始处插入等待；这不是处理它的最有效方法，但是由于所有顶点处理均已执行，因此到那时设置事件的可能性很好。

对于其他类型的命令，请记住，在渲染过程中发生的所有事情的依赖图都是在VkRenderPass本身中定义的。子 channel 依赖关系图在那里。您甚至不能在渲染过程中发出普通的vkCmdPipelineBarrier，除非该子过程在子过程相关性图中具有明确的自相关性，否则就不能这样做。

因此，如果您不能等待在该子 channel 或下一个子 channel 中完成操作，则在子 channel 的中间发出计算着色器分派(dispatch)或内存转移操作有什么好处？如果您不能等待操作结束，则无法使用其结果。而且，如果您不能使用它的结果，则最好在渲染过程之前发布它。

您不能拥有其他依赖项的原因可以追溯到TBR。依赖图是渲染过程的不可分割的部分，以允许TBR预先知道子过程之间的关系是什么。这样一来，他们便可以知道是否可以构建理想的渲染器，以及何时何地可能出现故障。

由于渲染遍历的TBR模型使这种等待变得不切实际，因此没有必要发布这样的命令。