vlambda博客
学习文章列表

评价一款游戏的性能好坏，我们通常会用到「帧率」（每秒钟的渲染帧数）作为主要参考指标。当然，手游这块功耗也是一个重要因素，但主要还是看帧率。像MOBA、FPS类的游戏，帧率肯定是越高越好，出于功耗与显示设备的限制，一般跑满也就在60fps左右。而像其他的棋牌、放置类游戏，帧率只要有30fps就足够了。

性能优化要谨遵「二八原则」：20%的代码影响80%的性能瓶颈。因此要合理地找出性能瓶颈所在，避免负优化。下面就三个比较常见的方面：「bandwidth」、「drawcall」、「overdraw」 来分别阐述渲染阶段是如何造成性能瓶颈以及对应的解决办法。

Bandwidth

移动端的GPU设计之初，优先注重的肯定是功耗问题，然而在实际渲染一帧图像的时候，对功耗影响最大的因素就是「带宽（bandwidth）」。

为什么会是带宽呢？

这是因为出于空间的考虑，手机芯片的设计上采用了SoC架构，因此内存与显存实际上是共享在一块物理内存上的，在OpenGL ES规范中，内存与显存中的数据却不能共享。在有限带宽的前提下，我们不妨计算一下，一台分辨率为1920*1080的移动设备，按60帧率来算，每秒钟1次overdraw产生的数据量为：

❝

1920 * 1080 * 32 * 60 / (1024 * 1024) = 3.7 Gb

❞

如果遇到了大量的半透明物体或是粒子特效，那么数据量上可能会成倍的增长。

如此大量的数据存储在显存的FrameBuffer中，GPU要以高昂地代价频繁地去显存访问FrameBuffer里的数据，这显然是很难接受的。因此在移动端的显卡硬件上，想到了一种优化方式，就是将FrameBuffer拆分成不同的小块(tile)，每次可以先将这一小块的数据放到访问速度更快的On-Chip Memory中去，GPU会先从tile中一块块地去进行渲染，等整体渲染完成之后，再将数据搬回显存上。

我们将这种模式称为 「TBR（Tile Base Rendering）」。

然而在TBR模式下，可能存在着这样的一个问题，如果对于CPU每一次传来的绘制命令都进行渲染的话，那么GPU必定会频繁、大量地对tile数据进行搬迁操作，这显然是不可接受的。为了解决这个问题，TBR一般的策略是：对于CPU提交的Draw Call请求，先只做顶点处理，将Vertex Shader计算的结果暂存到一个叫 「FrameData」 的地方。等到执行 「Swap Buffer」 的时候，再对整个数据做光栅化，进行绘制。

既然是等所有的FrameData数据处理好后一次性进行绘制，GPU硬件上便进一步做了些延迟渲染相关的优化。例如iOS上的PowerVR，专门有一个叫 ISR 的硬件，会去处理FrameData中那些诸如深度测试、模板测试没有通过的数据，尽可能地只去渲染那些最终影响FrameBuffer的物体。

我们将这种模式称为 「TBDR（Tile Base Deffered Rendering）」。

基于移动端GPU特有的架构模式，需要我们做哪些优化方面的事情或是注意事项呢？

• 使用压缩的纹理格式，如ETC、PVR等
• 打开Mipmap（内存与带宽的权衡）
• 减少Shader中的采样次数，尽量合并一些通道图
• 控制总顶点数量
• 不要频繁地切换FrameBuffer（后处理效果）

Drawcall

手机上CPU与GPU的关系，就好像客户端与服务端的CS架构。所谓Drawcall，可以理解为Client端的CPU向Server端的GPU发送的一次绘制命令，同时会传递需要被渲染的图元列表。现代GPU就为了「高并发」处理数据而生的，一般Drawcall的绘制数据计算起来应该还是绰绰有余。但由于CPU传递的渲染数据得通过PCI-E总线才能传到GPU显存中的全局存储区域，频繁且大量地提交绘制相对简单的绘制命令，会造成GPU端的“ 产能过剩 ”，CPU无法及时提供渲染数据而造成性能瓶颈。

与此同时，TBR架构下优化过的GPU，会先将顶点数据存储到FrameData队列，如果Drawcall数量过多，且顶点数量巨大，万一FrameData承装的内存放不下了，就得先将数据移动到别处，进而大大降低了访问速度。这也是我们需要控制DrawCall数量和顶点数的一个重要原因。

游戏开发中，常见的降低Drawcall的方式，无非以下几种：

动态合批

❝

在每一帧都对需要的网格进行合批处理，这样的好处就是合批的物体仍然可以各自移动，但是必须使用同一个材质。当所需合批的顶点数过多时，其实会对CPU产生额外的计算开销。因此在做动态合批的时候，通常会有顶点数的限制，需要根据实际需要做好取舍。

❞

静态合批

❝

只进行一次合批处理，生成一个大的网格，性能优于动态合批，但没有动态合批灵活（只能作用于静态物体），并且会有较高的内存占用。

❞

Shader LOD

❝

根据机型或摄像机距离，使用不同的材质shader，尽可能地降低细节表现，去除不必要的渲染Pass以及计算开销。

❞

遮挡剔除

❝

常见于大世界场景的游戏中，对于摄像机可视范围之外的物体可以进行视锥体剔除，但是可视范围内的那些已经被遮挡住了的物体，可能仍然会去进行绘制，造成不必要的性能损耗。

❞

Overdraw

对需要绘制的物体进行排序，是游戏引擎规避性能开销的一种常见手段。非透明物体相对摄像机由近及远地排序绘制，可以有效剔除那些深度测试不通过的片元。但对于那些未被遮挡（深度测试通过）的「透明物体」，由于需要开启混合计算，因此在Early-Z阶段也没法剔除掉那些背后的图元数据，这就造成了同一个像素的多次(过度)绘制，即我们常说的 「Overdraw」 。

GPU中跟Overdraw有关的指标可以参考「像素填充率」，即每秒所能渲染的最大像素数量。在确保带宽没有遇到性能瓶颈后（改用压缩纹理格式），如果降低设备分辨率后，帧率一下子上去了，那么很可能就是像素填充率遇到了瓶颈。这时候就需要看看Overdraw是否在一个合理的范围内，是否有优化的空间。

实际的游戏开发中，最常见的Overdraw大户莫过于「粒子特效」了。美术同学在制作粒子特效的时候，往往会为了追求细节效果而忽略掉Overdraw的问题。大量的透明粒子相叠加，造成的性能开销是十分可怖的。为此，我们最好在立项之初就设定好一些粒子特效的制作规范，或是一些建议要求来约束美术设计粒子效果。

❝

1. 一个复合粒子系统（如爆炸），子特效尽量不要超过5个（叠加过曝也应考虑优化）
2. 粒子所占的屏幕面积尽量不要过大，可以考虑使用Mesh来替换
3. 纹理中透明不可见的部分尽可能地少

❞

为了照顾低端机型，我们可以对粒子特效采取分级的策略，等级越低，特效表现越简单，同时也可以从粒子数量、运算模块来进行精简。如果还是不能满足性能要求，也可以考虑改用帧动画来替代粒子特效。