OpenGL ES 使用同步渲染模型，这意味着 API 调用必须表现得好像所有早期的 API 调用都已被处理。实际上，没有现代 GPU 以这种方式工作，渲染工作负载是异步处理的，同步模型是由设备驱动程序维护的精心制作的假象。为了保持这种错觉，驱动程序必须跟踪队列中的每个渲染操作读取或写入了哪些资源，确保工作负载以合法顺序运行以避免渲染损坏，并确保需要数据资源的 API 调用阻塞并等待资源安全可用。
Vulkan 使用异步渲染模型，反映了现代 GPU 的工作方式。应用程序将渲染命令排入队列，使用显式调度依赖关系来控制工作负载执行顺序，并使用显式同步原语来对齐依赖的 CPU 和 GPU 处理。
这些更改的影响是显着降低图形驱动程序的 CPU 开销，但代价是要求应用程序处理依赖关系管理和同步。
有人可以帮助解释为什么异步渲染模型可以减少 CPU 开销吗？由于在 Vulkan 中，您仍然需要自己跟踪状态。
【问题讨论】：
谁能帮助解释为什么异步渲染模型可以 减少 CPU 开销？
首先，让我们回到你所指的原始陈述，强调我的：
这些更改的影响是显着降低 CPU 图形驱动程序的开销，[...]
所以这里的说法是驱动程序本身需要消耗更少的 CPU，而且很容易看出它可以更直接地“按原样”转发您的请求。
但是，像 Vulkan 这样的低级渲染 API 的一个总体目标也是总体上可能降低 CPU 开销，而不仅仅是在驱动程序中。
考虑以下示例：您有一个渲染到纹理的绘制调用。然后你有另一个从这个纹理中采样的绘图调用。
为了获得正确的隐式同步，驱动程序必须跟踪此纹理的使用情况，作为渲染目标和纹理采样操作的源。
它事先不知道下一个绘图调用是否需要任何仍需在之前的绘图调用中写入的资源。它必须始终跟踪所有可能的此类冲突，无论它们是否会在您的应用程序中发生。它的决定也必须非常保守。您可能有一个用于绘制调用的帧缓冲区的纹理绑定，但您可能知道使用您为此着色器设置的实际统一值，纹理不会被修改。但 GPU 驱动程序无法知道这一点。如果它不能排除 - 绝对确定 - 资源被修改，它必须假设它是。
然而，你的应用程序会更喜欢知道这样的细节。如果您有多个渲染通道，并且第二个通道将取决于第一个渲染到的纹理，您可以（并且必须）添加适当的同步基元 - 但 GPU 驱动程序不需要关心为什么 根本不需要任何同步，而且它不需要跟踪任何资源使用情况就可以发现——它可以按照它的指示去做。在许多情况下，您的应用程序也不需要跟踪它自己的资源使用情况。在您对其进行编码时，使用它只是固有的，在某些时候可能需要同步。在某些情况下，您可能仍然需要跟踪自己的资源使用情况以找出答案，特别是如果您编写一些中间层，例如一些更高级的图形库，而您对渲染结构的了解越来越少 - 那么您就是进入类似于 GL 驱动程序必须做的事情（除非您想像 Vulkan 那样将所有同步负担转嫁给库的用户）。
【讨论】：