一种基于Metal、Vulkan多线程衬着能力的衬着架构

宾利雅致 · 发表于 2024-7-15 17:58

随着3D衬着场景规模越来越复杂，单线程衬着架构在满足业务性能要求时已经捉襟见肘，因此，多线程衬着显得愈发重要。本文首先介绍了新一代图形衬着接口Metal、Vulkan，以及它们的多线程衬着特性，然后描述了一种优雅的衬着架构，可以解决衬着管线开发中的诸多困扰，而且基于此实现了多线程衬着，极大的提升了3D衬着效率。

一、布景

Metal[1]、Vulkan[2]是分袂由苹果（Apple）和科纳斯组织（Khronos Group）面向新一代图形措置器（GPU）设计的图形API。在移动平台上，Metal应用于iOS系列产物，Vulkan主要由Android系统提供。Metal、Vulkan作为新一台的图形API，相较于OpenGL（ES），设计了更底层、更细粒度的接口，提供了全新的状态打点，改善了错误措置机制，增加了新的特性撑持。
使用新一代的图形衬着接口，可以全方位的增强3D引擎的衬着能力。比如使用状态缓存机制，可以降低CPU负载；操作ray tracing的三角面求交能力，可以带来全新的全局光照方案（Global Illumination）；自定义显存打点器，可以提高显存操作率……本文受限于篇幅，无法从各个角度逐一而述，这里主要讨论新一代图形衬着接口带来的多线程衬着能力，以及如何围绕它设计一种衬着架构。

二、多线程衬着

凡是一个单线程衬着引擎会面临着硬件资源浪费的问题。如下图1所示，一个CPU线程需要先负责逻辑更新，然后反复更新衬着状态，提交衬着指令。这种架构同时造成了CPU和GPU闲置。对CPU而言，完全可以将这些任务分配给多个CPU线程并行执行；就GPU而言，CPU线程在进行逻辑更新和提交衬着指令时，GPU处于闲置状态，浪费了算力。

图1 单线程衬着面临的问题

作为开发者，在不考虑功耗、散热、资源分配等现实限制条件下，凡是但愿CPU、GPU永远处于满负荷状态。为了达到满负荷的状态，每个线程凡是需要具备三个基本能力：

资源创建打点
Pipeline创建打点
Command Buffer创建打点（提交Draw Calls）

如果使用OpenGL（ES），引擎开发者将面临的最大问题是，OpenGL（ES）API不能跨线程调用，它们的调用只能局限在GL Context创建线程内，这也就意味着OpenGL（ES）无法原生撑持多线程衬着。为了达到OpenGL（ES）多线程衬着的目的，开发者需要手动实现Command Buffer，记录图形调用指令，考虑数据线程安全问题，解决资源同步可能带来的性能损耗，不胜其烦。而这些问题，已经在metal、vulkan设计者考虑之内，新一代的图形API天然撑持跨线程调用，让多线程衬着变得更具有实践可行性。如下图2所示，使用Vulkan时，Thread 1、2、3独自组织更新工作，写入Command Buffer，最后提交到Thread 4中的Command Queue中。

图2 Vulkan多线程衬着架构

三、小结与转进

从上面的描述可以看到，新一代的图形API为了提高硬件资源操作率，进行了全新的设计，似乎多线程衬着唾手可得，衬着效率即将走向巅峰。然而，如果到此为止，急冲冲拿着多线程衬着API试图提升衬着效率，进行实践时，才会发现脑子里一团乱，无从下手。毕竟上面只是简单描述了图形API的基本能力，并没有提供任何实际可行的方案。就比如做菜，有一样的原料，做出来的菜品可能千差万别。不外下面不筹备直接描述一种多线程衬着方案，先转进到一个相关问题—Render Graph。
四、Render Graph

Render Graph在有些文献也称之为Frame Graph，这里使用Render Graph一词，主要是考虑到与Shader Graph[3]一词呼应。附录对Shader Graph有一个简单描述。
Render Graph是基于数据驱动的理念，将行为与数据解耦。只不外是Shader Graph措置shading相关问题，Render Graph措置rendering相关问题。下面先了解下，衬着器开发时遇到的一些痛点问题，然后了解下Render Graph如何解决这些痛点。

4.1 网状布局的衬着流程

从图3可以看到，一个常见的衬着系统，包含了地形、粒子、全局光照、反射、PBR、后措置、天空……各种模块，而这些模块还具有彼此依赖关系，形成网状布局，实际开发中会导致一系列令人沮丧的问题，简单举例：

记忆难度大。即使衬着系统由一个专人负责，过了一段时间之后，也很难对整个衬着流程记得分毫不差。
不易了解衬着流程全貌。阅读线性布局的代码，来理解图状布局的流程，非常困难。
日常维护难。为了撑持新的衬着特性，经常需要向已有的流程中添加新的模块，新的模块意味着需要打断与重建各模块之间的联系，稍有不慎，就会犯错。
资源打点困难。比如motion blur和Temporal Anti-Alias都需要使用velocity buffer，一旦衬着流程中各种开关过多，那么确定velocity buffer创建、销毁时机就变得异常困难。如果采用粗暴的设计方式，就会变成衬着开始阶段创建velocity buffer，直到衬着生命周期结束才销毁velocity buffer，占用了紧缺的GPU资源。更加糟糕的是，即使精妙的设计了velocity buffer创建和销毁时间，后续衬着流程稍有改动，这个所谓的精妙设计反而变成了错误设计，作茧自缚，心智承担极重。
模块打点困难。比如 shadow map模块，如果某个场景中不需要使用暗影，那么shadow map模块就不应该执行。为了达到这种开关效果，往往实际中成立一系列的if分支判断，决定流程是否执行。但这种带有“土味”的方式，会使衬着流程更难理解，代码bug极容易发生。

图3  Frostbite衬着系统

一系列令人头疼的问题，实践过的人会大白，痛不欲生，Render Graph应运而生。

4.2  Render Graph应用在延迟衬着上

图4  延迟衬着流程使用Render Graph描述

要讲清楚什么是Render Graph，最好的方式是直接看一个Render Graph例子。如上图4所示，它描述的就是一个延迟衬着流程的Render Graph，从中可以看到橙色的方框代表的是行为（operation），蓝色的方框代表的是资源（resource）。在实践中，引擎中使用一个基类RenderGraphRenderPass来定义行为，使用一个基类RenderGraphResource来定义资源。这样在实现RenderGraph时，需要经历三个阶段：

构建阶段。在此阶段中需定义所有RenderGraphRenderPass、并为其定义输入输出RenderGraphResource。资源类型分为两种，permanent和transient。Permanent一般是Render Graph的外界资源，比如back color buffer之类。Transient资源可按照读写属性分为三种，只读资源，可写资源、内部创建资源。
编译阶段。在这个阶段，Render Graph可以自动的按照配置剔除无效行为和数据，而且自动的计算资源生命周期。
运行阶段。执行代码，完成整个衬着流程。

有了Render Graph，数据和行为得到解耦，加上清晰的数据流，很好的解决了4.1节提到的诸多混乱。比如，如果需要在上面的延迟衬着流程中添加Screen Space Ambient Occlusion（SSAO），只需要将全部的精力集中在SSAO的算法实现上，实现一个RenderGraphSSAORenderPass，然后定义好输入输出，不用关心现有的衬着流程如何复杂。然后在Render Graph中设置好AO相关节点，连接好相应的数据流，整个过程就完成了。

4.3  复用延迟衬着衬着流程

在4.2小节中定义了一个延迟衬着的Render Graph，在本节可以看看如何复用这个Render Graph来实现新的功能。从图5可以看到，对于延迟衬着的绝大部门流程，不必做改变，只需要把Lighting Buffer拷贝到cube map之中，然后进行卷积，就可以得到反射球。

图5  复用延迟衬着生成反射球

4.4  剔除无效数据和行为

在4.2小节中提到了， RenderGraph第二阶段是编译阶段，会进行无效行为和数据剔除。如下图6所示，这里本来Gbuffer是作为Lighting render pass的输入，此刻改为Debug View render pass的输入，然后拷贝到Final target上，就可以显示衬着中间变量，用来进行调试。此时Lighting render pass及其相关资源和render pass就变成了无效资源，可以直接在编译阶段剔除。

图6  剔除Lighting及其相关资源

4.5  异步执行的Compute Shader

除了常见的衬着单元，现代图形架构中还存在着不成忽视的计算单元（Compute Shader）。Compute shader相较于衬着单元，将精力集中在计算方面，类似于光栅化这种衬着单元中的尺度法式，在计算单元中不复存在。可以简单的认为，在执行通用计算时，compute shader的效率优于fragment shader。因此，一个完整的衬着架构不成回避通用计算模块，可以定义一个基类RenderGraphComputePass来描述这个功能。
既然同时有了RenderPass和ComputePass，就需要考虑RenderPass和ComputePass是否串行执行。考虑到RenderPass和ComputePass都涉及大量IO访谒和图形API提交，GPU有可能处于闲置状态，因此将RenderPass和ComputePass进行并行设计。如图7所示，因为SSAO功能考虑使用compute shader实现，那么SSAO相关功能放到此外一个异队伍列中。因为异步设计，同时会造成相应资源的生命周期耽误，增加了整体显存消耗。

图7  上部和下部分袂描述了SSAO的同步和异步设计

4.6  小结

基于Render Graph的衬着管线架构，数据流清晰，维护容易，高度可配置，甚至可以做到为每个衬着场景定义一套独特的衬着管线，最大化的操作硬件效率。
那么这一切和本文提到的多线程衬着有什么关联？
五、基于多线程衬着的Render Graph

站在更高角度抽象的去看Render Graph， Render Graph是一个有向无环图。如图8所示，执行C依赖F的完成，但D并不依赖F，也就是C、F必需串行执行，而D、F可以并行运算。因此只要对这个有向无环图进行拓扑排序，系统便可以自动判定任务并行性，这就是多线程衬着的切入点。如果具象的理解这个问题，可以认为任务D是Gbuffer pass，而任务F是shadow pass，那么D和F不存在彼此依赖关系，可以并行计算。

图8  Render Graph的抽象形式

这里设计了一种拓扑排序方式：

统计各节点出度和入度。D、F入度为0，具备并行性，出度分袂为1、2。E的入度为1。
执行入度为0的节点。执行D、F，F任务结束后，将它指向的节点入度减去1，这样E的入度变为0。
反复执行第二步，直到整个Graph执行完成。

颠末上面的操作，整个Render Graph变成线性执行关系，最后提交给常规的并行系统执行，如图9所示。

图9 拓扑排序Render Graph tasks并执行

六、总结

本文首先介绍了Metal、Vulkan的多线程能力，然后使用Render Graph作为衬着架构，最后操作了一种简单的拓扑排序方式，将有向无环图展开为线型执行布局，使Render Graph天然撑持并发的特性得到阐扬，能够充实操作新一代图形API的多线程衬着能力。
本文受限于篇幅，主要探讨新一代图形API的多线程衬着能力，其它方面来不及深究。此外，CPU逻辑的并行能力也没有来得及阐述，但愿未来有机会进一步进行补充。

作者简介

饶超，2018年插手快手，图形引擎开发工程师，负责特效图形引擎设计与开发。
附录

Shader Graph主要是按照数据驱动的理念，将行为（shading）和数据解耦。下面图10展示了Unreal Engine 4 Shader Graph的UI界面。UI最右边面板含有Base color、Metallic、Roughness、Opacity等等slot，其余的部门为这些slot提供数据。这种设计，引擎内部可以不用关心data provider（整个Shader Graph就是一个data provider）具体逻辑，直接拿到这些数据，进行进一步的shading。Shader Graph具体实现本文不做深入探讨，它与多线程衬着并没有太多的关联。

图10 Unreal Engine 4 Shader Graph

引用

[1] Metal Programming Guide：https://developer.apple.com/library/archive/documentation/Miscellaneous/Conceptual/MetalProgrammingGuide/Introduction/Introduction.html
[2] Vulkan：https://www.khronos.org/vulkan/
[3] Unity3D shader graph：https://unity.com/shader-graph

快手Y-tech介绍（公众号同名）

Y-tech团队是快手公司在人工智能范围的探索者和先行者，致力于计算机视觉、计算机图形学、机器学习、AR/VR等范围的技术创新和业务落地，不竭探索新技术与新用户体验的最佳结合点。Y-tech在北京、深圳、杭州、Seattle、Palo Alto有研发团队，成员来自于国际知名高校和公司。
持久招聘（全职和实习生）：计算机视觉、计算机图形学、多模态技术、机器学习、AI工程架构、美颜技术、特效技术、性能优化、平台开发、东西开发、技术美术、产物经理等标的目的的优秀人才。如果你对我们做的事情感兴趣，欢迎联系并插手我们，一起做酷炫的东西，缔造更大的价值。
联系方式：y-techservice@kuaishou.com
AIGC开放平台：即将上线，敬请等候～

		自动登录	找回密码
密码			立即注册

一种基于Metal、Vulkan多线程衬着能力的衬着架构

本帖子中包含更多资源