从 Metal 看 Vulkan —— 重用还是重建

Apple 给自己的图形系统取名 Metal 之意在于强调其开销很低,图形应用程序如同直接运行在「金属硬件」( bare metal ) 上。但对 Metal 和 Vulkan 都有了解的人直观上会感觉后者更复杂也更直接反映硬件细节。「Metal 并不能像 Vulkan 那样程度地直接操作硬件」是 Khronos 和 Vulkan 拥趸的一贯观点。

Metal 和 Vulkan 的差异有很多值得讨论之处。绝大部分是前者相对后者在概念上的合并和简化。本来想写篇长文逐一说明,后来决定先拿出 commnad buffer 重用这个问题在一篇 blog 里详谈。

Metal 和 Vulkan 的 command buffer 作用基本相同,用来记录一组 command [1]。记录完成后通过 commit/submit [2] 发送给 GPU 执行。Metal command buffer 在 commit 之后从 CPU 看来已成为「废弃」状态,除了等待其在 GPU 执行完毕之外不能再进行任何操作。而 Vulkan 可以在一个 command buffer 被 submit 并执行之后,再次 submit。这就是 Metal 缺乏的 command buffer 重用功能。

Command buffer 重用的作用如何?下面对比普通数据 buffer 的用法来衡量一下。这里不谈体积较大且很少变化的 vertex/image buffer 等等,只谈体积较小而且每个 frame 都会变化的参数 buffer。不论 Metal 还是 Vulkan,数据 buffer 都可被重用。实际上,低开销图形系统都建议在开始渲染前预分配所有数据 buffer。但是这里有一个概念被偷换的问题,数据 buffer 的「重用」并不等同于 command buffer「重用」。前者只是表明省略了「分配」步骤,但是 buffer 的内容依然可以,而且在绝大多数情况下确实每个 frame 都被 CPU 更新。已经记录完毕的 command buffer 是一个 immutable buffer,重用 command buffer 是原封不动的重用整个 buffer 在上一个 frame 用过的内容。所以通常意义上的数据 buffer 重用是指「预分配重用」,而 Vulkan 所谓的 command buffer 重用是指「内容重用」。之后的讨论中会避免不严格的「数据 buffer 重用」和「command buffer 重用」的说法,而是在不同 buffer 类型的使用场景中讨论「预分配重用」和「内容重用」。

不论 Metal 还是 Vulkan,command buffer 的「预分配重用」都不是一个问题。因为任一时刻内同时被使用的 command buffer 数量不多,不存在数据 buffer 那种动态分配的复杂性,所以 command buffer 总是从一个 pool 中进行分配,并不存在分配开销很大的问题。虽然在 Metal 中 command buffer 被设计成一种生命周期通常限于单个 frame 的 transient object,但是从「预分配重用」方面看和数据 buffer 并没有区别。

另一方面设想一下能否把「内容重用」应用到数据 buffer 上。这其实不太容易。渲染中每个 frame 的资源需求基本相同,「预分配重用」只需要用简单逻辑估计所有 frame 需要的资源之和进行分配即可。但是渲染中数据内容的变化是复杂的,判断数据是否在 frame 之间发生了变化需要复杂得多的逻辑。判断数据变化的逻辑本身就会很复杂,而且由于涉及 triple buffer 或者 swap chain 机制,衡量数据变化的时间段并非两个直接相邻的 frames,而是要基于整个 in-flight frame 的周期,且不同 in-flight frame 周期之间是相互重叠的。所以在实际工程中,通常在每个 frame 对数据 buffer 进行「暴力更新」而不考虑内容重用。这是软件复杂度的合理取舍。数据 buffer 如此,command buffer 的重用自然也面对同样难以绕开的困难。

上面的讨论围绕在不同 frame 间的资源重用。那么 command buffer 重用是否在这个场景之外有更好的用途?实际上,command buffer 和固定的 render attachments 绑定 [3] 决定了其在不同的 render pass 或者 frame 之间进行重用比数据 buffer 更加受限。同一 render pass 内又有 instance draw 这种更好的重用的方式。

Command buffer 重用看来是一个 API 设计欠考虑,实际适用场景罕见的功能。给人的感觉是因为 GPU 有了命令队列 replay 的能力,所以不加考虑就在 API 里放出来,「only because we can」。虽然现代 GPU 给了图形系统的开发者存储和重用更多类型数据的机会,但是如何设计对应的上层抽象是值得慎重考虑的问题。

脚注:

  1. Metal command buffer 并不直接记录 command,而是通过创建 encoder 对象来完成这个工作。Vulkan 虽然是用 command buffer 来记录,但在开始记录前会将其设置为一个或者多个 render pass,其开始和结束对应了 Metal encoder 的 life cycle。
  2. Metal 称为「commit」;Vulkan 叫做「submit」。
  3. 其绑定通过上面提到的 Metal encoder 和 Vulkan render pass 体现。

一条回应 to “从 Metal 看 Vulkan —— 重用还是重建”

  1. Linker Lin Says:

    Vulkan似乎只有谷歌支持的最起劲。比较麻烦。
    看PS5的支持如何吧。

发表评论

Fill in your details below or click an icon to log in:

WordPress.com 徽标

You are commenting using your WordPress.com account. Log Out /  更改 )

Google+ photo

You are commenting using your Google+ account. Log Out /  更改 )

Twitter picture

You are commenting using your Twitter account. Log Out /  更改 )

Facebook photo

You are commenting using your Facebook account. Log Out /  更改 )

Connecting to %s


%d 博主赞过: