合批

简介

批量渲染，也叫“合批”，动态合批与静态合批其本质是对将多次绘制请求，在允许的条件下进行合并处理，减少cpu对gpu绘制请求的次数，达到提高性能的目的。

为什么合批

批量渲染是通过减少CPU向GPU 发送渲染命令（DrawCall）的次数，以及减少GPU切换渲染状态的次数，尽量让GPU一次多做一些事情，来提升逻辑线和渲染线的整体效率。但这是建立在GPU相对空闲，而CPU把更多的时间都耗费在渲染命令的提交上时，才有意义。

调用Draw Call性能消耗原因是啥？

我们的应用中每一次渲染，进行的API调用都会经过Application->Runtime->Driver->显卡(GPU)，其中每一步都会有一定的耗时。
每调用一次渲染API并不是直接经过以上说的所有组件通知GPU执行我们的调用。Runtime会将所有的API调用先转换为设备无关的“ 命令”（之所以是设备无关的，主要是因为这样我们写的程序就可以运行在任何特性兼容的硬件上了。运行时库使不同的硬件架构相对我们变的透明。）
Draw Call性能消耗原因是 命令从Runtime到Driver的过程中，CPU要发生从用户模式到内核模式的切换。
模式切换对于CPU来说是一件非常耗时的工作，所以如果所有的API调用Runtime都直接发送渲染命令给Driver，那就会导致每次API调用都发生CPU模式切换，这个性能消耗是非常大的。Runtime中的Command Buffer可以将一些没有必要马上发送给Driver的命令缓冲起来，在适当的时机一起发送给Driver，进而在显卡执行。以这样的方式来寻求最少的CPU模式切换，提升效率。

每次调用DC
将一些没有必要马上发送给Driver的命令缓冲起来，在适当的时机一起发送给Driver
解决渲染Batch过多的主要方法：

合批
一个是对Driver进行优化，降低Driver的性能开销。

合批优化的是CPU还是GPU？

合批只是对CPU的优化，与GPU没有任何关系

合批是节省了CPU的相关准备工作的工作量。

合批后，经过VS,PS，尝试测试，模板测试后，此时已没有了纹理，顶点，索引的概念，只剩下一个个孤立的像素，各像素间没有任何关系了。像素送到GPU后进行批量处理，呈现到屏幕硬件上。因此合批与GPU没有任何关系，也几乎没有影响。不管是一批还是多批，最终在此帧送到GPU的像素数量是相等的，数据是相同的。合批与否，对GPU的影响仅是像素到达的慢了还是快了，几乎不影响GPU的性能

目前比较新的图形API如：DirectX12、Vulkan、Metal，在Driver上的性能消耗已经降低了很多。但是通过合批来降低渲染的Draw call仍然是十分必要的。这也是我们对Draw call优化唯一能够做的事情。

静态合批

一般合批的对象是场景中不能动的物体，静态物体，并且在inspector界面勾选上static选项；Unity预先组合静态GameObjects的网格，然后将组合的数据发送到GPU，但单独渲染组合中的每个网格，静态合批不会减小drawcall，只是减少了渲染状态的改变次数。Unity仍然可以单独筛选网格，但每次绘制调用都不会占用大量资源，因为数据的状态永远不会改变。在Unity开启Static Batching，依次点击 Edit > Project Settings > Playe->Other Settings->enable Static Batching。对于Unity使用静态合批的具体要求可以参照官方文档

支持静态合批的Unity渲染管线：默认渲染管线、URP（通用渲染管线）、HDRP、SRP。

在运行时，通过脚本使用静态合批：Unity提供了运行时，通过脚本使用静态合批口：StaticBatchingUtility.Combine，这是一个静态方法，通过这种方式调用静态合批，就不需要在编辑器的inspector界面勾选上Static选项。

static Batching缺点与限制：使用静态合批会增加内存！，因为使用静态合批，需要在内存中存储合成的几何体数据；如果多个GameObject使用了相同的网格数据，Unity会为每一个GameObject创建一个网格副本，这就意味着相同的几个数据有可能会出现多次！所以如果内存过大，就尽量避免使用静态合批。对于每一次静态合批，顶点数的限制时64000，如果超过这个值，Unity就会再次创建另外一个批次(Batch)。

动态合批

动态合并在满足以下条件时时自动完成：

模型总顶点属性数小于 900。例如，材质的shader使用了位置、法线、UV坐标，那么顶点数就是900 / 3 = 300，如果使用了vertex position, vertex normal, UV0, UV1, 和 vertex tangent，那么顶点数量的限制就是 900 / 5 = 180；
不包含镜像 transform 改变。不改变 Scale。
如果使用动态 lightmap 需要指定正确。
不使用多 Pass 的 Shader。
不修改材质球
由于需要在合并时通过 CPU 计算转为世界坐标，这项技术只在 CPU 消耗比 DrawCall 消耗“便宜”时才值得。这个衡量标准会根据平台产生差异，例如苹果平台上 DrawCAll的消耗便宜，就不应该使用这项技术。这个功能可以在 Editor–> Project Setting –>Player 中进行设置打开与关闭。