unity3d引擎缓存优化技术_移动平台Unity3D 应用性能优化

Draw Call 的优化

前面说过了,DrawCall是CPU调用底层图形接口的操作。比如有上千个物体,每一个的渲染都需要去调用一次底层接口,而每一次的调用CPU都需要做很多工作,那么CPU必然不堪重负。但是对于GPU来说,图形处理的工作量是一样的。

我们先来看看Draw Call对CPU的消耗大概是一个什么级别的量:

NVIDIA 在 GDC 曾提出,25K batchs/sec 会吃满 1GHz 的 CPU,100%的使用率。有一个公式可以和清楚得计算出在给定的CPU资源 与 帧率的情况下,最多能有多少个DrawCall。

DrawCall_Num = 25K * CPU_Frame * CPU_Percentage / Framerate。

DrawCall_Num : DrawCall数量

CPU_Frame : CPU 工作频率(GHz单位)

CPU_Percentage:CPU 分配在DrawCall这件事情上的时间率(百分比)

Framerate:希望的游戏帧率

比如说我们使用一个高通820,工作频率在2GHz上,分配10%的CPU时间给DrawCall上,并且我们VR要求60帧,那么一帧最多能有83个DrawCall(由于双camera的存在,单眼DrawCall只能保证在41个以内)。其实,google官方的建议是单眼DrawCall不多于50个。

所以对DrawCall的优化,主要就是为了尽量解放CPU在调用图形接口上的开销。所以针对drawcall我们主要的思路就是每个物体尽量减少渲染次数,多个物体最好一起渲染。那么DrawCall次数的优化有哪些方案呢?

DC Batching(DC批处理)

batch即批处理,DrawCall batching即DC的批处理,即把多次DrawCall合并成一次DrawCall的方案。

Dynamic Batching 动态批处理

Unity引擎对于使用相同材质的物体会自动进行批处理,相同材质意味着shader完全一样,这一部分主要是要注意那些破坏这一特性的人为因素,比如说:

1、批处理动态物体需要在每个顶点上进行一定的开销,所以动态批处理仅支持小于900顶点的网格物体,如果你的着色器使用顶点位置,法线和UV值三种属性,那么你只能批处理300顶点以下的物体(如果在这基础上还使用了UV2,则只能批处理180顶点以下的物体);请注意:属性数量的限制可能会在将来进行改变。

2、使用不同的缩放比例的物体,unity将无法对这些物体进行批处理。比如(1,1,1)和(1,2,2)就不会动态批处理,但是(1,1,1)和(2,2,2)会动态批处理。

3、拥有lightmap的物体含有额外(隐藏)的材质属性,比如:lightmap的偏移和缩放系数等。所以,拥有lightmap的物体将不会进行批处理(除非他们指向lightmap的同一部分)。接受实时阴影的物体也不会批处理。

4、多通道的shader会中断批处理操作(为了达到特殊的渲染目的,可能某个物体要多遍渲染.这是就要多个通道)。

5、在脚本中动态地指定了物体的材质,也不会进行批处理。

Static Batching 静态批处理

动态批处理虽然是自动的,但是限制非常多,不小心就会打破批处理,所以unity在专业版中还提供了静态批处理,静态批处理要求是想批处理的物体一定是static的,静态的,不会改变位置和旋转角度以及缩放的,且必须材质一致。其原理是把物体的网格进行合并,变成一个静态的更大的网格物体,再使用一个统一的材质进行渲染。

知道了它的原理,它的某些坑就比较清晰了:

1、在一个平行光、环境光下,没有问题,但是如果你使用了多个平行光,点光源,聚光灯这种复杂的光源去照射物体,那么静态批处理就会被打断。(项目中就遇到过,因为两边有两排英雄模型,所以场景中使用了两个不同平行光,场景中勾选的static物体并没有被合并drawcall,经过一番折磨才找到原因)。

2、如果静态批处理前有一些物体共享了相同的网格,那么每一个物体都会有一个该网格的复制品(本来unity只会保留一份,但是静态批处理会生成新的一个大网格,所以会保留所有物体的网格,最后合并),即一个网格会变成多个网格被发送给GPU。这样会造成内存的使用变大,需要注意这个问题,但是一般场景中使用相同网格的物体会比较少。

3、对于那些shader相同,纹理不同导致的不同材质无法进行批处理的物体(比如项目中的场景环境,基座,地面,其实都使用了unity自带的standard shader)可以通过纹理合并的方法来使得它们可以被静态批处理。这就引发了下面的事情:

BUS总线带宽

CPU完成一次DrawCall,除了需要发一个DrawCall的命令之外,还需要把内存中顶点数据、纹理贴图、shader参数通过bus总线拷贝到内存分配给GPU的显存之中,注意这是拷贝,不是指针传递,速度不快。如果一次drawcall传递的数据过大,带宽成为了瓶颈,那就会大大影响效率(其它的DrawCall无法出发,GPU又处于闲置)。这种情况最有可能出现在为了减少DrawCall,疯狂的合并纹理上。在项目中,UI的DrawCall调用占了很大一部分,也会最难优化的,为了减少drawcall ,我们把UI模块的静态部分(一些UI的底板,背景等不会发生变化的)全部合并成了一个纹理,最后导致了DrawCall下降了,但是帧率却也下降了,内存使用也增加了,原因就是这个。在项目中,不会同时出现的元素不要打包到一起,保证单张合并纹理不大于1024*1024一般就不会有问题了(王者荣耀最大纹理限制在了256*256)。

DrawCall的优化大概就是这些,优化的目标其实是往一个目标上靠,cpu的DrawCall命令刚刚好能被GPU消化,不要让CPU等待(带宽限制),也不要让GPU闲置。如果即使做到了这个,应用帧率还是上不去,那么就只能去削减场景,做有损优化了。

你可能感兴趣的:(unity3d引擎缓存优化技术)