【Unity】图形渲染瓶颈与批处理优化
【Unity】图形渲染瓶颈与批处理优化
图形渲染
工作方式
显卡的工作方式并非连续的，一般分三步。
- 上传更新渲染数据至显存
- 设置显卡的渲染管线状态
- 启动绘制并等待绘制结果
性能瓶颈
由于显卡是大规模并行计算，绘制几个或几千个三角面在速度上基本没有区别，这时候瓶颈就容易出现在工作方式中第一第二点上。
-
内存到显存的传输是有代价的
如果对比过 Unity 的作业系统就会发现一点，对应一些数据量大但计算量小的任务，使用计算着色器的速度反而比作业系统要慢的多。
原因就是因为计算量小导致显卡的强大计算能力没法体现，结果时间全花在了大量数据的传输上，不如直接用 CPU 就地解决。
-
处理器与显卡的沟通是有代价的
此时数据已经传输到了显存中，但具体使用那些数据，哪种绘制方式，这些都需要进行设置，这就需要 CPU 与 GPU 进行沟通。
同第一点，这是两种不同的硬件，交流本就有延迟，再加上 GPU 因此切换内部状态的时间，那就更长了。
优化方案
由此可见我们应在两个方向上进行优化
- 减少显存中数据的更新频率
- 减少显卡中工作状态的切换
诸如网格，纹理，着色器，常量缓冲区等这些都是需要存储在显存中的，因此应仅可能减少其内容的修改。
如果可以，尽可能多物体共用这些资源，这不仅仅可以减少缓存的使用，还可以减少调整渲染状态的次数。
具体例子
最原始的渲染方案，我们可能每个物体都要单独渲染一次，即使不考虑显存大小的问题，我们每次也都要重新设置渲染用的目标数据和状态，还没正式让 GPU 工作，仅设置 GPU 的环境就花费了很多时间。
然后当我们正式启动 GPU，结果因为单个物体的计算量较小，GPU 瞬间就好了，这时又要进入缓慢的准备阶段，让 GPU 一直空等着。
这很类似早期的单道批处理操作系统的问题，IO 时间与处理速度不匹配，所以我们要增加处理速度的时间并减少 IO 的次数。
比如我们可以合并多个物体的渲染数据，并确保他们可以使用同样的着色器和渲染管线状态，从而将它们变成一个完整单一的大型物体。
此时渲染这一个物体依然可以变相实现渲染多个物体的效果，但每个物体间不再有准备时间，GPU 也能跑更长的时间了，CPU 不再需要动不动停下来指挥 GPU 做事，并行能力也大幅提高。
渲染批处理
渲染批处理即是上述优化方案的具体实现。它将有共通属性的多个物体看成同一组甚至同一个，以批为单位进行渲染。
在 Unity 中渲染模型需要两种图形资源，材质+网格：
- 材质包含了常量缓冲区，渲染状态，着色器的数据。
- 网格包含了顶点、索引缓冲区的数据。
物体能被一起渲染，说明他们用到的数据都一样，也因此如果希望物体能被识别为同一批，只要确保他们用到的材质和网格一样即可。
材质的共用
-
使用纹理图集功能
对于因纹理不同而导致材质差异的情况，可以尝试用该功能将纹理合并成一个，接着只要在网格的 UV 上进行特殊处理即可保留原功能的同时合并材质。
因为 UI 和 Sprite 是自动生成的网格，所以可以自动兼容 Unity 中的图集设置，简单设置就可轻松获得性能优势。
-
使用 GPU 实例化功能
GPU 实例化是一种特殊的渲染方式，由底层图形引擎提供，可以实现一次显卡调用但自动保留环境的同时多次绘制同一网格，同时会在着色器阶段传递这些网格的绘制编号。
利用这些编号做区分我们便可为不同的网格采取不同的绘制数据，从而实现一次调用却好像使用了不同材质多次绘制的效果。
网格的共用
-
静态批处理
提前自动将选择的多个网格合并成一个“大网格”，所有原本的模型将共享该网格中的顶点索引缓冲区等，这样绘制时只要直接绘制一次这个大网格即可。
当然该网格的渲染也不一定是完全正向的，因为共用一个大网格也意味着没法进行剔除等操作，过多看不见的三角面被渲染，可能导致得不偿失。
-
动态批处理
和静态批处理的原理一样，但区别是实时的，所以必须每帧都要考虑重新生成用于批处理的大网格，也因此存在性能问题：生成网格的消耗可能比渲染批处理节省的开销要大。
因此只能用于小型网格的合并，主要还是用于对过去旧低端设备进行优化，目前并不是太推荐。