一些未来Unity开发可能用到的技术（Unite2025）

🕒2025年11月03日 11:00:00 | 📖-- | 💬-- | 🏷️ #技术 , #unity , #游戏开发

📝1595 个字 | ⌛要看完怎么也得4分钟吧

简要概述

因工作之便，有幸参加了今年在上海举办的Unite2025大会。大会一共持续两天时间，主要是团结引擎相关的内容，除此之外还有很多其他领域的内容，包含发行、车载、小游戏以及一些优化案例相关的。
而我因为现在使用的比较多的还是国际版的Unity，所以本次的目的其实主要还是冲着优化案例去的，希望能从前辈们那学到一些不一样的东西。
游戏案例的分享整整持续了一天的时间，前前后后有不少的项目案例，所以相对来说内容非常庞杂。回来之后就开始紧锣密鼓地整理分析会上的一些记录，也如期发现了不少之前没注意到的新内容，所以这里主要记录一下这部分知识，以备之后不时之需。

GPU Resident Drawer（GRD）

功能概述
- 自动使用BatchRendererGroup接口，以GPU instancing的方式渲染GameObject，从而同时减少CPU和GPU的消耗。同时GRD保持了原有的GameObject + MeshRenderer的渲染方式，从而让使用BatchRendererGroup的技术门槛得到了大幅度的降低。
  - 关于BatchRendererGroup，因为相比之下已经是老接口了，所以这里就不再单独展开了，具体可以看看Unity官方的接口文档。但值得一提的是，该接口确实在性能表现上有非常大的空间，Unity也是一直在不断简化这套接口的使用门槛。从最早的内部使用，到开放API，再到API重构和现在的GRD，可见该接口的重要性。
- 截取一些团结引擎官方介绍上的图片，首先可以发现的是，新的GRD渲染流程中，通过将绘制相关数据保存至GPU Buffer，使得每帧只需要修改对应数据，而不用再单独创建RenderNode。同时在绘制的时候，不再是每个RenderNode单独触发Drawcall，而是通过GPU instancing批量绘制一个相同配置的Pass，因此可以同时为CPU和GPU节省下不少的开销。
- 这是官方的一些优化数据对比，也雀食印证了使用GRD技术，可以带来新的性能优势。
适配情况
- unity 6，团结引擎 1.6+

Variable Rate Shading（VRS）

功能概述
- VRS可以使片段着色器，在保留光栅像素的边缘的情况下，一次着色一个以上的像素，从而减少GPU的渲染压力。
- 截取一些Unity官方介绍的图片，例如一张16x16像素的图片，在2x2 VRS的情况下，每个片段着色器最多可以一次着色2x2=4个像素，因此实际只需着色4次。而在4x4 VRS的情况下，则只需要1次着色。
- 具体前后效果的对比，可以参考一下NVIDIA的演示视频，虽然丢失了一些细节，但只要不钻牛角尖，基本肉眼不可得。
- Unity官方也提供了一份VRS技术的demo，感兴趣的话可以下载体验一下。从数据上可以非常直观的看到，使用4x4 VRS的情况下，GPU的渲染时间得到了大幅度的减少，但画质上几乎感受不到区别。
适配情况
- unity 6（移动端安卓需要支持vulkan，没提metal所以推测是暂不支持）
- 团结引擎1.4+（和unity基本保持一致）

GraphicsStateCollection

功能概述
- Unity内用来封装管线状态对象（Pipeline State Object）的载体，是一个包含各种着色器变体和图形状态的集合。着色器变体的收集功能类似于ShaderVariantCollection，但额外收集了图形状态信息。
  - 什么是Pipeline State Object（PSO）
    - PSO本质上就是单次绘制时，渲染管线所处状态信息的集合（Shader、混合器状态、光栅器状态、图元拓扑信息等）。
    - PSO是为新式图形API（Vulkan、DirectX12 和 Metal）提出的新概念。相比于较老的图形 API（OpenGL、DirectX11），PSO工作流程具有更好的性能发挥。
    - 不同的图形API对PSO的称呼不一致，但本质上都是一个概念。
  - 为什么使用PSO？
    - 旧版工作流程
      - 由于旧式API提供了各种设置图形状态的接口（如glSetBlendState），因此用户可以在任意时刻随意改变图形状态。因此驱动为了正确渲染，只能等到在真正开始产生DrawCall时，再统一收集一遍当前的状态信息，并设置GPU工作状态。因此会导致CPU状态切换开销大，GPU工作效率低等问题。
      - 除此之外，一些着色器如果在游玩时实时编译，会产生大量的计算，从而导致卡顿（ShaderVariantCollection就是为了解决这一问题）。
    - 新版工作流程
      - 规定PSO对象一旦创建，就不允许再进行任何修改（如着色器、混合状态、颜色掩码等）。而后续渲染流程只面向PSO对象，从而实现数据解耦，驱动程序也不需要再跟踪管线状态。
      - 不同的渲染状态，可以生成不同的PSO，因此只需切换不同的PSO就可以改变管线状态。同时切换PSO的过程，相对来说开销更低，速度更快。
      - 通过显式预热所有PSO对象，可以保证后续的游玩过程，无需额外的开销（如shader编译等）。
- 通过使用GraphicsStateCollection，可以在运行时动态记录遇到的着色器变体和图形状态，并生成对应缓存文件。而下次运行时，通过在合适的时机提前预热生成的缓存，即可实现后续渲染不再进行重复的计算。
效果演示
- 截取一些Unity官方介绍的图片，从profiler的数据和实机演示可以明显看出来，运行时创建GraphicsStateCollection，容易导致大量的计算消耗，从而最终导致游戏低帧顿卡。
适配情况
- unity 6.1+支持gles（相关api仍处于experimental状态）
- 团结引擎暂时没找到对应的文档，但在路线图中可以找到相关信息，预计明年也能推出相关的技术支持。