Unity 2017 Game Optimization 读书笔记 The Benefits of Batching

batching(合批) 和大量的描述一个3D物体的数据有关系,比如meshes,verices,edges,UV coordinates 以及其他不同类型的数据。在Unity中谈论batching,指的是用于合批mesh数据的两个东西:Dynamic Batching(动态合批) 和 Static Batching(静态合批)。渲染管线特别喜欢处理合在一起提交的mesh数据而不是单独的一个个的mesh数据。

Draw Calls

在讨论Dynamic Batching(动态合批) 和 Static Batching(静态合批)之前,先理解下Dynamic Batching(动态合批) 和 Static Batching(静态合批)要解决渲染管线的问题:降低用于绘制当前视图所有物体的Draw calls。

Draw call是从CPU发送到GPU的一个请求,用于物体的绘制。在Draw call请求之前,需要完成一系列的准备工作。

首先,mesh和textrue数据必须从CPU 的内存(RAM)推送到GPU内存(VRAM),对于已经存在于场景里的,这通常发生在场景初始化的时候。对于预先没有在场景内的,只能在它们被instantiate的时候进行该操作。其次,cpu必须为gpu准备渲染所需要的设置和数据。cpu和gpu之间的通信是通过不同平台的图形API来完成的,有可能是DirectX,OpenGL,Vulkan等等。

API通过驱动程序调用,大量繁杂的渲染管线渲染物体所需的设置信息通常被叫做Render State。在Render State改变之前,GPU都将会一直使用这个Render State来渲染物体。对Render State做改变是一个开销非常大的过程,比如我们设置Render State使用一张蓝色texture去渲染mesh,这会将整个mesh渲染成蓝色,我们可以再渲染9个完全不同的mesh,它们都会被渲染成蓝色,因为我们没有改变使用的texture。但是如果我们想渲染10个mesh哟个10张不同的贴图,就会十分耗时,因为需要渲染每个mesh时都去准备新的贴图信息发送draw call。越少更改Render State,图形api处理我们的请求就会越快。

能触发Render State同步的操作包括但不限于:添加实时的texture到GPU,修改Shader,修改灯光信息,修改阴影和透明度等等有关渲染的设置。

CPU和GPU之前通过Command Buffer保持通信,这个队列存储了CPU创建好的用于渲染的操作指令,GPU在每次完成渲染指令后再从这个队列中获取。

一个新的Draw Call并不意味着必须有一个新的Render State。合批能够提供渲染性能的原因是如果俩个物体使用同样的RenderState信息来渲染,GPU就可以立刻渲染下一个物体,这消除了Render State的同步时间,合批同样可以减少渲染的指令数量,减少CPU和GPU的负荷。

Materials and Shaders

Unity中通过Materials来把Render State暴露给我们。Materials是一个Shader的容器,shader本身并不感知实际的Render State,shader所需的diffuse textures,normal maps等实际就是隐式的Render State变量。

每一个shader都需要一个Material,一个Material也必须有一个Shader。因此如果我们想减少Render State的变化,我们可以通过减少场景中Materials的数量。CPU每帧会消耗更少的时间来生成和传输渲染指令,GPU也不需要频繁停下来重新同步Render State的变化。

做个实验,四个cube,四个sphere,各自不同的material,关掉shadow,关掉dynamic batching 和 static batching:

结果为9个batches(还有一个是背景,比如天空盒)

Unity 2017 Game Optimization 读书笔记 The Benefits of Batching_第1张图片

像之前介绍的那样,我们可以减少material数量来提高效率,如果都用同样的material会是什么效果:依然还是9个,这是因为我们没开启Dynamic Batching,渲染管线并不能够意识到需要重复使用Render State。

Unity 2017 Game Optimization 读书笔记 The Benefits of Batching_第2张图片

The Frame Debugger

Unity中调试渲染非常有用的工具,可以查看每一帧的渲染过程,对于跟踪场景中DrawCall来源,优化游戏非常有用。这一小节就不详细介绍了

Unity 2017 Game Optimization 读书笔记 The Benefits of Batching_第3张图片

 Dynamic Batching

三个特性:

1. 运行中实时动态合批

2. 根据主摄像机视野中可见的物体,每一帧合批的内容都可以不同

3. 运动的物体也可以进行合批

上一小节的例子,开启动态合批后结果为:6个batches,这是因为4个Sphere因为不满足动态合批条件而没有进行合批。

Unity 2017 Game Optimization 读书笔记 The Benefits of Batching_第4张图片

动态合批的条件具体参考Unity的文档,这玩意随着Unity版本的变化不断在变化。

https://docs.unity3d.com/Manual/DrawCallBatching.html

动态合批需要满足的条件:

Unity 2017 Game Optimization 读书笔记 The Benefits of Batching_第5张图片

  • 使用相同的材质引用
  • 只有ParticleSystem和MeshRender可以合批,SkinnedMeshRender等其他Component无法合批.Currently, only Mesh Renderers, Trail Renderers, Line Renderers, Particle Systems and Sprite Renderers are batched. This means that skinned Meshes, Cloth, and other types of rendering components are not batched.
  • 每个mesh最多300个顶点索引。
  • 最多900个顶点属性 。
  • mesh的Scale要么都统一,要么都别统一(这句没看懂,令人费解)
  • 材质的shader不能使用多passes
  • mesh不能接收实时阴影
  • 合批后mesh总共的索引数不能超过各自平台的上限,一般是32k-64k个。

Vertex attributes

顶点属性是每个顶点的一系列信息,比如位置,法线,UV等。如果每个顶点3个属性,则如果想合批,可以最多支持的顶点数是900/3 = 300。如果每个顶点5个属性,则最多可以持的顶点数是900/5 = 180。要注意的是即使顶点属性少于3个,合批最多也只能支持300个顶点(另外一条规则)

Mesh scaling

奇数个负数Scale不能合批,比如(1,-1,1),偶数个可以(1,-1,-1)

Dynamic Batching summary

  • 适用于场景中含有大量简单的物体,比如大片有石头和树木的森林等。
  • 如果只是单纯的texture不同,可以考虑使用图集的方式,这样就可以合批。
  • 如果场景中有很多个比较简单的物体,但是只有少数可以合批的话,还不如不开启合批,因为遍历场景判断合批的操作可能更费。
  • 动态合批的条件非常苛刻,经常会出现打破了合批规则而自己不知道,所以要多注意,要经常不定期的去调试check来保持Draw call的合理值,当然,常常的状况是我们直到Draw Call真的成为性能瓶颈影响表现时,并不需要去考虑Draw call。
  • 最后一条建议,多尝试,看看哪些不能合批哪些能合批来保证Draw call

Static Batching

Unity 提供了第二种合批方式,那就是Static Batching。Static Batching的条件:

  • 物体必须被标记为Static
  • 需要额外的内存
  • 合批后mesh总共的索引数不能超过各自平台的上限,一般是32k-64k个。
  • mesh可以不同,但是必须使用相同的材质引用

The Static flag

要小心如果只是把物体标记为Batching Static,运行时可能会产生奇怪的现象:mesh由于Static Batching没有移动,但是Rigidbody什么的可能会动。

Memory requirements

额外的内存开销是Static Batching的一个缺点,Static Batching copy 需要合批的mesh的数据到一个单独的大mesh buffer中,并将其传入渲染管线中通过一个Draw Call进行渲染,完全忽略掉原始的mesh。如果需要合批的mesh都是不同的,那是否使用静态合批内存的开销是一样的。然而如果渲染的是相同的object,则内存开销会翻倍,平常渲染一个,10个或者100万个同样object的clone花费的内存开销是一样的,因为他们引用的是相同的mesh 数据,对于每个Object唯一不同的只是transform。然而Static Batching 需要copy mesh 数据到大的buffer中,这种引用关系就没有了,每个物体都会将原始的mesh数据copy到buffer中。因此使用Static Batching 渲染1000个tree的内存开销是不使用Static Batching的1000倍,所以在使用Static Batching时要慎重,要判断使用的是否合适。

Material references

有时候,Static Batching会需要处理多个Materials,在这种情况下,每个Material会被分组到各自的Static Bathc中,也就是说Static Batching可以用和Materials数量相等的Draw Call渲染所有的静态meshes。

Static Batching caveat & Edit Mode debugging of Static Batching & Instantiating static meshes at runtime

  • Static Batching 不能在编辑器中立刻查看效果,只能运行起来后看效果,调试起来非常麻烦
  • 运行时将物体动态标记成Static并不会被合批,但是可以通过 StaticBatchUtility.Combine() 强制合批,但是要非常谨慎使用,这个函数开销极大

Static Batching summary

Static Batching 是一个十分有用但是又十分危险的工具,如果使用的好会给渲染带来提升,如果使用的不好,内存的开销以及各种其它弊端都会很蛋疼。

Summary

Dynamic Batching 和 Static Batching summary都是有用但是又有风险的工具,要真正搞明白它们才能正确的使用它们。第六章会更多更深入的介绍Dynamic Graphics。

 

GPU Instancing

此处加一点书中这章没写的内容,GPU Instancing也会有效降低DrawCall,它的原理详见

https://learnopengl-cn.github.io/04%20Advanced%20OpenGL/10%20Instancing/

GPU Instancing 非常高效,它的要求也更高,不仅要求Material引用一样,mesh也必须一样,因为mesh一样所以才不会存在Batching合并大mesh带来的内存开销。

Unity Batching优先级:静态合批 > GPU Instancing  > 动态合批

 

 

 

 

 

 

你可能感兴趣的:(Unity,优化)