近日，第八届中国图学大会正式召开，作为中国图学界最高级别的双年学术会议，为全国从事图学研究、教学与应用的一线工作者，以及从事数字化设计、数字化制造、数字化服务和制造业信息化的一线研究者提供了一个良好的交流平台。
本届大会的“Web3D 引擎分论坛”，邀请了相关领域的专家、学者共同探讨 Web3D 引擎技术未来的发展之道，围绕如何打造中国自主原创的 Web3D 引擎及如何奠定中国 Web3D 引擎的国际地位展开热烈、深入而广泛的研讨。Cocos 引擎技术总监凌华彬受邀出席，发表了《基于 WebGPU 打造次时代 Web 3D 内容》主题演讲。
Cocos 引擎令人惊叹的 Web 3D 能力
今天我分享的主题是“Cocos 基于 WebGPU 打造次时代 Web 3D 内容”。Cocos 希望用技术推动数字内容行业的效率提升，不仅包含游戏行业，还包含元宇宙、汽车、虚拟角色、XR 等行业，下面先展示一些 Demo。
Cocos Web 3D Demo：Lake
基于 Web 端的延迟渲染管线，是比较少有的在 Web 端落地的复杂渲染管线，包含反射、ssao、bloom、fsr、taa 等高级效果。
Cocos Web 3D 元宇宙：美的 True Space
美的基于 Cocos 引擎做的元宇宙应用，有很多可玩的空间，渲染效果也非常的好。这是目前市面上标杆级别的元宇宙应用，其使用 Web 端分发的触达优势也非常明显。
Cocos Web 3D 元宇宙：WAIC 元生无界
Cocos 为世界人工智能大会打造的在线会场，包括原生端、Web 端，我们还发布了 XR 端，大家可以用 PICO 和 Oculus 的设备去体验。
Cocos Web 3D Game：代号剑仙
基于 Cocos Creator 研发，拥有精美的纯 3D 画面，并且具备跨平台、跨终端的特性，实现了多端数据互通。
Web 3D 的未来
Web 3D 是适合非常多的应用场景，是一个非常务实的落地选择，因为它的成本非常低，并且可以触达到所有的用户，不管用户是在什么操作系统、平台、环运行环境，都可以访问到你所打造的内容。所以我们也认为在元宇宙时代，Web 3D 会成为一个非常主流的访问平台和内容搭建平台。
从发展历程来看，Web 3D 的未来就是 Web GPU。从OpenGL 到 OpenGLES，再到包含 Web 端的 WebGL，虽然服务的是不同的平台。但是到今天已经逐步要被下一代的 API 所替代了。
OpenGLES 已经被 Vulkan 取代，WebGL 的下一代 WebGPU 也正在开发当中。WebGPU 封装了所有的次时代的渲染图形后端：Metal、Vulkan 和 DirectX。因为浏览器本身是需要跨平台的，所以 WebGPU 是以跨平台为最优先的考虑来进行图形后端的设计。
2014 年、2015 年、2016 年分别诞生了苹果的 Metal API、Windows 和 Xbox 的 Direct X12、以及 Khronos 的 Vulkan，覆盖了 iOS、MacOS、Windows、Android 等平台。
2017 年 W3C GPU for the Web 工作组成立，致力于设计 Web 平台的下一代图形接口 WebGPU，所有的浏览器内核厂商都已经宣布未来将会在自家浏览器中支持 WebGPU。
2018 年，OpenGL ES 已经在 iOS 12 中被废弃，OpenGL 在 MacOS Mojave 中被抛弃。
从历史发展来看，GL 家族已经完成历史使命，需要新一代的 API 去替代。
次时代图形 API 的第一个特点是 Command Buffer 的设计。
传统的 OpenGL 其实是直接把指令提交到 GPU，不管是切换渲染状态、切换管线状态或是渲染一个 DrawCall，都是直接提交到 GPU 并且 GPU 直接执行。现代图形 API 是先录制到 Command Buffer 当中， 再提交到 GPU 一起执行所有的 Command Buffer，所以它变成了一个延迟模式的渲染。这样的模式帮助我们更好地理解整个渲染全路径和流程，并且也支持多线程的并行录制，这一点非常重要，因为现在渲染的内容越来越多，尤其是在元宇宙，需要非常大的 3D 场景，非常多的物件和角色，需要有大量的 Command Buffer。多线程的并行录制在 CPU 端是一个非常大的优势。
第二是 Pipeline State Object，PSO 抽象了整个 GPU 的渲染管线状态，以前 OpenGL 是一个状态机，不管改变什么东西，都是直接去改变它。但是在次时代图形 API 里面，PSO 变成了一个可控的 GPU 渲染管线状态切换的一个对象，可以用来直接进行整个 GPU 渲染管线的切换。
第三是 Resource Binding，通过上层的 Resource Binding 自主地去管理。Pipeline Layout 和 Descriptor Set Layout，这两个对象去把所有的场景中的摄像机、材质、物件相关的全部信息都收集起来，并且形成一个一个的 PSO，交给 GPU 去进行 PSO 之间的切换，而不是一个状态流转到下一个状态。这样的方式可以让整个渲染管线变得更加可控，自由度完全交给了上层的开发者，并且可以做到非常的高效，因为你可以更好地去管理状态之间的切换。
第四是 Thin Driver，从隐式预测，到显式声明。次时代渲染图形 API 的驱动层都是很薄的，从 OpenGL 通过 Driver 层去预测在 GPU 层需要什么样的操作，变成了必须要自主地显示地去声明，包括显示的同步管理、Barrier 的同步管理、以及内存的管理。像 Resource Binding、Binding layout 这些都需要手动管理的，这样图形程序就拥有更强的控制力和更大的责任。我们相信这样的未来可以让整个管线更适合各种应用场景和应用。因为当 Driver 特别厚的时候，驱动需要对通用的需求进行预测，而当开发者拥有更多的控制力的时候，可以针对自己的图形应用来做出更针对性的优化。
WebGL 是 OpenGL ES 的映射，而 WebGPU 则是统一现代图形接口的一个抽象，它会直接去对接所有的现在图形接口，而不再是对接 OpenGL 这样的一个映射关系了。
WebGPU 的 Runtime 是直接封装对接到所有的图形后端，实现包括 dawn/gfx-rs/webkit。Google 的 dawn 实现，其实是一个很好的对现代图形后端封装对一个参考。
最后就是 WebGPU 支持更多的 GPU 特性，包括 Compute Shader、Ray Tracing 等等。WebGPU 天然就会支持 CS，这也是我们迎接未来的一个很好的理由。
关于 WebGPU 的现状，所有的浏览器厂商都在逐步对接当中，尤其是 Chrome，2023 年 3-5 月就会支持 WebGPU。目前主流的引擎支持有 Babylon、Three.js 以及 Cocos Creator。
Cocos 拥抱下一代图形标准 GPU
Cocos 是一个跨平台的渲染器设计，跨平台体现在 GFX 的封装上。从底层，我们的 GFX 对不同的图形 API 的适配都被统一成一套接口，这个接口其实是比较接近现代图形 API 的，支持 Command Buffer、PSO、Pipeline State Layout、Pipeline Layout、Descriptor Set Layout 等概念。所以 Cocos 去适配 WebGPU 是非常快捷且简单地。
往上一层，我们有自己的 RenderGraph 的设计。RenderGraph 其实是把上层的渲染场景中的信息进一步的抽象，然后交给 GFX 层。这里我们做了许多优化工作，包括对材质、场景、模型里面的 PSO 的收集，把它们用 Descriptor Set Layout 组织起来，并结合 Pipeline Layout，推导出 PSO，并且提前固化，最后在渲染的时候尽可能只做 PSO 之间的切换。这是一个非常高效的优化。
同时，我们也把整个渲染管线变成了一个 Render Graph 渲染管线。我们会先对渲染管线做一遍推导，然后再去执行整个渲染管线，生成出所有的 Command Buffer。我们还基于 RenderGraph 实现了 Forward 管线和延迟管线，也收到了非常好的效果。
在 WebGPU 上，我们第一次封装的实现是基于 JS ，在 TypeScript 里面实现了整个 gfx-wgpu 去对接到 WebGPU JS API，直接由 TypeScript 的 render-pipeline 来使用。去年 3 月份就已实现，出于现实考量并没有继续推进下去。
我们后来推动到了一个 C++ 层的使用方案，在 C++ 层实现自己的 gfx-wgpu，通过 Emscripten 来编译成 WebAssembly，并且在浏览器里面通过 WebAssembly 执行所有的 GFX 指令。
未来我们会进一步把 render-pipeline 和 GFX 编译成一个 renderer 的 WebAssembly。目前我们所有的 renderer，尤其是 render graph 的实现，都已经在 C++ 层，所以这是一个更自然的选择。走向 C++ 的适配路线，是因为更多面向未来的基础设施都是在 C++ 层实现的。
最后，Shader 方面也是需要注意的地方，上图我们引擎的一个适配管线，但实际上每一个引擎，每一个应用开发者都需要去面对这个问题。当你要适配 WebGPU 的时候，我们目前只能使用 SPIR-V 或者是 WGSL 这两种格式，而且 SPIR-V 目前只是在 Chrome 里面短暂的支持，很快可能会被移除。
所以我们现在的编译流程如下：上层用户写的是 GLSL，它需要被编译成 GLSL 的 460 版本和 100 的版本。100 的版本才能运行在 WebGL1. 0 和 OpenGL2. 0 上面。460 版本我们会继续编译成 SPIR-V。SPIR-V 可以短暂的运行在 WebGPU 上面，并且也是我们在 Vulkan 上使用的主要的格式。
接下来我们还需要通过 Tint。Tint 也是 Chrome 在 dawn 面所实现的一个 Shader 的编译器。通过 Tint 把 SPIR-V 编译成 WGSL，运行在 WebGPU 上面。所以整个 Shader 的编译流程是较长且复杂的一个过程。
Cocos Creator 3.6.2 已经正式支持 WebGPU。发布 Web Desktop 时勾选 WebGPU 实验性功能即可实现。
因为我们的 GFX 可以封装掉所有的后端差异，所以对于开发者来说是完全不可见的。开发者只需要开发自己的游戏，不需要做任何额外的工作，就可以发布到最新的 Web GPU 后端上。这里面也包括 Metal、Vulkan，无需额外工作，就可以享受到现代图形 API 所带来的优势。
这个 Demo 的场景里面有 3000 多万面的三角形，模型的精度非常的高，场景非常复杂，也可以非常高效的运行到 60 帧。
最后分享一下我们在 WebGPU 适配上遇到的坑和经验。当前 WebGPU 和 WGSL 仍然在草案阶段， API 还不是完全稳定，需要对标准对进展保持关注。
WebGPU 有自己的 Shader 语言。需要考虑怎么样把GLSL、HLSL 转换到 WGSL。
Chromium 目前适配进展最快的，最适合大家去进行调试和开发。也可以参考 Dawn 中的各种工具和实现。
WebGPU 的适配非常依赖 Validation layer 来进行调试和问题暴露，大家也尽可能不要去忽略一些 Warning。
现阶段更加推荐用 JS 来直接适配 WebGPU API，我们自己选择了 WASM 方案，其实是有很多自身的需求的考量，因为需要保持统一的底层实现。
Emscripten 也带来一些麻烦。对 WebGPU 接口支持可能会有些延迟，需要在尝试的过程中发现问题再去解决。
WGSL 暂时不支持 Combined 的 Image Sampler 也是我们遇到一个比较大的问题。在传统管线里，texture 和 sampler 的声明是合并在一起的，大家只需要声明一个 sampler。但是在次时代的图形 API 里，是建议单独声明 sampler 和 texture。
最后分享一下 Cocos 的架构目标。
首先，我们希望为系统性的性能天花板努力，而不是做单点的性能的优化。系统性的性能天花板提高了以后，让开发者有更大的空间能够发挥。
第二点是让跨平台开发尽可能的简单无缝。开发者简单通过一个勾选，就可以直接发布到 WebGPU，这是我们做得非常极致的一点。
第三点是面向未来设计的基础设施。这也是为什么我们要支持 WebGPU，2016 年底我们就决定更偏向 Vulkan、Metal 这样的现代 API，而不是基于 GL，现在看来有很大的回报。
第四点是将强大的次时代图形接口带给 Web 3D 的内容开发者。
最后是统一基础架构，降低引擎维护成本。这也是为什么选择 WebAssembly 的方案来去封装 Web GPU。
谢谢大家。
往期精彩
