opengles 性能调优

2019独角兽企业重金招聘Python工程师标准>>>

https://www.jianshu.com/p/35096e796aa3?utm_campaign=hugo&utm_medium=reader_share&utm_content=note&utm_source=weixin-friends&from=singlemessage&isappinstalled=0

使用Mali Graphics Debugger调优Unity程序（Killer示例）

DonaldW

2015.08.07 21:42* 字数 2891 阅读 7031评论 5喜欢 17

What is MGD

ARM® Mali™ Graphics Debugger的作用之一是针对采用ARM® Mali™ GPU的Android手机，进行app的GPU运行时调试和调优。

Why MGD

本文MGD主要用于性能调优。

关于GPU性能调优，定性不定量都是耍流氓。
猜是虚的、打嘴炮讨论是无用的、运行时正则表达式disable对象是盲目的、Unity Profiler是难于真机调试的、GPA（Intel® Graphics Performance Analyzers）是不同平台的、Unity FrameDebugger是从实现本质决定了不能定量到高于DrawCall精度的。

另外，本文假设已确定瓶颈出现在GPU。否则，应优先调优CPU性能。直接使用Unity真机调试是不错的CPU性能调优手段。

Doc & Setup

阅读[ARM® Mali™ Graphics Debugger User Guide](http://malideveloper.arm.com/downloads/tools/mgd/1.3.2/Mali Graphics Debugger v1.3.2 User Guide.pdf)是了解MGD最全面的途径，里面包括了如何设置MGD和使用MGD。
由于MGD里会直接出现大量OpenGL/OpenGL ES的API，所以也可按需查阅AW OpenGL ES 3.0 Programming Guide 2nd Edition。

本文以MGDv2.1版本为基础进行编写。编写完毕后数天（约2015-08-11）得知MGDv3.0已发布，其改进了体验和UI框架、FrameBuffer View、支持MRT/DepthBuffer/StencilBuffer的截取、更好的截取性能和截取文件大小优化。详情可参考官网或[Mali Graphics Debugger 3.0.0 User Guide](http://malideveloper.arm.com/downloads/tools/mgd/3.0/Mali Graphics Debugger v3.0.0 User Guide.pdf)。

关于MGD设置，本文为了内容完整性也精简地描述如下。（你若已设置好或暂不关心设置，也可跳过以下设置步骤，直接阅读下面的操作步骤、思考过程和发现killer的问题及其以下章节。）

• 在电脑装好MGD
• 准备好Mali GPU的Android手机。基于Mali的设备不少，比如Samsung Galaxy S3等基于Exynos SoC的手机。具体列表见Mali SoC implementation。
• 本文用已Root的Android的设备进行。但未Root也可用，但需要参考上面User Guide，以另外的方式进行。
• 在电脑上安装好ADB（Android Debug Bridge），并且把ADB设置到操作系统（windows or OSX）的环境变量中。
• 连接Android设备和电脑。
• 打开命令行，输入：

#拷贝mgd版OpenGL ES运行时库和mgd后台进程到手机sdcard文件夹
cd /your_computer/path_of_installed_mgd

adb push libGLES_mgd.so /sdcard/
adb push mgddaemon /sdcard/

#准备进入手机进行命令行操作
adb shell
#以下命令在手机中执行
su
#拷贝mgd版OpenGL ES库和mgd后台进程到手机system文件夹并且修改为可执行权限
cd /sdcard/cp mgddaemon /system/bin/mgddaemon
chmod 777 /system/bin/mgddaemon
cp libGLES_mgd.so /system/lib/egl/libGLES_mgd.so
chmod 777 /system/lib/egl/libGLES_mgd.so

#Android 4.2 和 4.3切换到mgd版OpenGL ES运行时库：改egl.cfg配置方式
cp /system/lib/egl/egl.cfg /system/lib/egl/egl.cfg.bak
echo "0 0 mgd" > /system/lib/egl/egl.cfg

#Android 4.4 and 5.0切换到mgd版OpenGL ES运行时库：文件链接方式
cd /system/lib/egl
ln -s libGLES_mgd.so libGLES.so
ln -s libGLES_mgd.so libEGL_mgd.so
ln -s libGLES_mgd.so libGLESv2_mgd.so
ln -s libGLES_mgd.so libGLESv1_CM_mgd.so

#设置mgddaemon，叫它只调试com.tencent.killer这个进程。这里应填入你自己的进程id
echo "com.tencent.killer" > /system/lib/egl/processlist.cfg

#先退回到电脑，可能不止一次exit
exit

#准备打通调试信息转发通道
adb forward tcp:5002 tcp:5002

#再次进入手机，启动mgd后台进程
adb shell
su
mgddaemon

• 在电脑上打开MGD，如下图点击Connect按钮

   

  

  点击Connect按钮，连接MGD和设备

• 运行killer（或你自己的app）
• MGD成功自动收集killer的GPU运行时调试信息

MGD成功自动收集killer的GPU运行时调试信息

至此，Setup操作已完毕。接下来，需要保持手机和电脑的USB连接，进行进一步的调试调优操作，亦可用通过菜单将当前调试数据保存到电脑。

操作步骤、思考过程和发现killer的问题

关于killer

killer（产品名字《独立防线》）为我们项目组一款基于Unity的可FPS/TPS切换、可PVP/PVE的3D射击游戏。

第一帧：主角第三人称状态，未露出FPS状态精细武器、无特效

在游戏中操作，进入战斗。并保持主角在主角第三人称状态，未露出FPS状态精细武器、无特效——一个最纯粹的战斗情况。

保持主角在主角第三人称状态，未露出FPS状态精细武器、无特效

 

从上图发现MGD已自动收集GPU数据，很是烦人，此时，可点击暂停按钮，暂停游戏，从而暂停收集。

点击Toggle Fragment Count按钮（注意之前的操作步骤如并非MGD和设备先Connect好了之后才运行app，可能会导致本按钮无法点击），再点击下一帧，可用收集下一帧的Fragment Shader的信息。这是因为Fragment Shader往往是性能消耗大户，需优先关注。

点击*Toggle Fragment Count*按钮，再点击下一帧

点击刚刚收集好Fragment Shader信息的第971帧，点击Fragment Shaders，然后按指令周期比例排序，可立刻知道哪些shader占消耗大头，比如图中的第877号shader，名字是“Shader 879”。

 

双击该877号shader，观察代码，可知是用于lightmap场景的shader

第877号Fragment Shader程序

 

所以，可输出结论一和初步解决方案。

结论一：场景是GPU性能消耗第一大户，需最优先关注。精简、优化场景mesh和贴图、精简lightmap是可行方法。

再点击下一个第619号Fragment Shader程序，

第619号Fragment Shader程序

通过经验可知，为渲染UI的Shader

 

UGUI的UI-Default.shader

 

所以，可输出结论二和初步解决方案。

结论二：UI是GPU性能消耗第二大户。留意到里面有discard语句，可能带来性能影响，所以应编写无clip版本的shader。并且精简UI、或进行UI纹理打包。

再点击下一个Shader，发现和UI Shader很相似，只是少了一个颜色的运算，所以也不用有mediump的color_2中间变量。可知是UGUI针对材质颜色为全白色时的优化版Shader

第622号Fragment Shader程序

 

所以，有结论三。

结论三：UI中，不需用颜色的，应保持此材质颜色为白色。

至此，当前帧的Fragment Shader权重较高者，皆已列出，剩下的Fragment Shader已变得性价比不高。
需转移目标，比如，Vertex Shader。
同理，切换至Vertex Shader，按cycle排序，找出性能消耗第一大户，第880号Vertex Shader。通过里面的代码出现“SH”，可知是球谐函数“Spherical Harmonics”，即用Light Probe进行渲染的主角Shader。

第880号Vertex Shader

 

所以，有结论四。

结论四：主角顶点数过多（图中为23469个顶点），是造成性能的瓶颈之一。

同时，留意到我们主角都是距离镜头很近的，所以，压根不需要雾的运算，所以，有结论五。

结论五：主角的Shader，甚至一些在不远处的敌兵shader，都需要去掉雾运算。

再观察下一个877号Vertex Shader，留意到是用Light Map进行渲染的场景，所以。

 

第877号Vertex Shader

 

同理，亦可以有结论六。

结论六：场景，如有可能，最好也去掉雾运算。

至此，第一帧分析基本完毕

第二帧：FPS状态，露出精细武器，无枪火特效

游戏战斗中是个多变的过程，不同时刻的两个帧显示的内容可能大相径庭。
所以需要更换另一种情况进行继续调优。比如FPS状态，露出精细武器，无枪火特效。

FPS状态，露出精细武器，无枪火特效

 

在之前的暂停状态下，取消点击收集Fragment数量按钮（Get the fragment count statistics），否则将会很卡，然后点击播放按钮（Resume Tracing），以和第一帧类似的方法进行数据收集。

取消Get the fragment count statistics，才继续进行操作

 

从收集数据看来，结果和第一帧数据并无质变。但由于知道变化的因素是精细武器本身，所以应特定确定该Shader的消耗。
此时，如果对武器Shader不熟悉，可以打开Unity，在Editor重现该情况，在Editor直接阅读Shader代码，如下：

精细武器的Shader：Bumped Specular

根据Shader特征Shininess、Gloss和Normalmap等，回到MGD，也是按Cycle数从大到小逐个观察（因为渲染武器的消耗肯定不会很小），确定为第871号Fragment Shader。

第871号Fragment Shader，用于精细武器的Bumped Specular Fragment Shader

 

所以有结论七：

结论七：精细武器的Shader的Cycle比例（4.6%）和Shader指令，哪怕是用Surface Shader，也不算复杂，不是瓶颈。这可能是因为Unity的按平台编译Shader的优化结果。

第三帧：FPS状态，露出精细武器，开火，播放开火特效

FPS状态，露出精细武器，开火，播放开火特效

 

继续采集数据。并且点击开火，触发开火特效，然后立刻点击MGD暂停，并进行类似采集。发现有以下新的问题shader。

第862号Fragment Shader占用了10%的cycles

通过观察Shader代码，和枪火特效（还有额外的四周防护罩效果）的Shader一致，为

特效Shader，Particles/Additivie

 

留意到该Shader并不复杂，但却又雾的处理（理论上可以去掉一个Tint的颜色乘法），并且该特效在Unity观察overdraw也合理，所以也可以有结论八：

在Unity观察枪火特效overdraw也算合理

 

在Unity观察防护罩特效overdraw也算合理

结论八：枪火特效+满屏的防护罩特效会导致有额外10%的cycle产生。需去除雾的处理。因为需求原因，占用屏幕面积较大，但Overdraw程度尚算合理。

至此，关于Shader的调优在本文暂告一段落。接下来需要更多实地考察。
另外，操作上还有小技巧，可以通过Frames with features enabled的过滤，剔除没有详细数据的帧

可以通过*Frames with features enabled*的过滤，剔除没有详细数据的帧

 

内存情况

内存不会直接影响帧率，但也是性能的一方面表现。过高的内存可能是加载缓慢的诱因、可能会提高app后台后被系统kill掉的几率、也可能直接导致内存不足crash。
点击MGD里的Textures，并点击Size进行排序。

点击Textures，并点击Size进行排序

 

当前在killer出现了不合理情况有：

不该在战斗出现的纹理泄露到了战斗

结论九：主界面的图标从战斗外泄露到战斗内了。需要注意是否战斗内有错误的引用。可使用运行时检测工具打包Sprite Packer的tag是否战斗外、战斗内互斥。亦需要注意资源模块ResourcesManager是否还有资源引用，导致Resource.UnloadUnused()无法卸载主界面资源。

一个时刻只出现一个的icon图片可以不打包

结论十：军衔图标可能从战斗外泄露到战斗内了，也可能是战斗内就是需要用到。
结论十一：一个时刻很大几率只出现一个的icon图片可以不打包，放弃一定的DrawCall效率来换取内存，并且这样哪怕泄露也可减缓泄露的后果。

尚未提及的更多性能评估点

本文着重从最根本的Shader的Cycles数量进行分析，但尚未提及的更多性能评估点包括：

• DrawCall是否合理，有否可能合并。Unity 3D游戏中，合并DrawCall会决定于LightMap，也会决定于UI层次间的atlas分布。
• 是否有过多的OpenGL状态切换。

更多的优化细节，也可参考ARM® Mali™ GPU Version: 3.0 OpenGL ES Application Optimization Guide，或ARM® Guide to Unity Version 2.1 Enhancing Your Mobile Games。

MGD（v2.1）尚待改进的地方

MGD（v2.1）尚待改进的地方有：

• 在本次调优过程中，不能对已Capture的帧进行逐DrawCall重画（用户手册给出了原因）；
• 不能方便观察顶点模型；
• 不能以柱形图直观地列出时间或Cycles消耗。

上述部分问题已在MGDv3.0得以解决。

About

DonaldW，客户端开发，现就职于腾讯魔方工作室群。
本文可随意分发、分享。但请注明署名。

转载于:https://my.oschina.net/u/269082/blog/1604013