众所周知,Android终端基本都配有GPU;无论手机还是VR,AR设备,GPU在其中扮演了越来越重要的地位。
当我们拿到一款GPU时,我们最关心的就是性能了。
不服跑个分。跑分是目前最常见的测试性能的方式。
1)我们最熟悉的GPU benchmark测试就是曼哈顿3.0\3.1测试了;
2)安兔兔的3D测试也是一个不错的例子,但是注意应用版本,不同版本总分是不同的。
可以说这个方法基本还是可靠的,但是缺点也是存在的:
1)GPU Benchmark的测试会尽量排除CPU带来的影响,但实际游戏中很可能并非如此,因此跑分与实际的运行环境表现迥异。另外与台式机不同,台式机中显卡游戏测试比较成熟,3A大作中耗CPU的,耗GPU的,耗RAM的都能找到一堆。但Android生态上就很难找到类似场景;(这个问题不在这篇文章讨论,会在后续文章中介绍)
2)在了解了具体参数之后,我们希望在本地能验证一下GPU具体的性能。可惜曼哈顿虽好,但是要翻墙,对于我们本地测试就非常麻烦。安兔兔负载不均衡,可能并不适合单一场景下的帧率和功耗测试;最重要的,如果GPU能力不强,比如高通8909平台,则安兔兔则可能仅有2,3帧的样子,根本无法有效测试正常场景下的表现。
基于上面的考虑,我们接下来介绍4个简单的Android GPU本地性能测试工具。
1. GPU渲染评估初期本地测试:Flatland**
在最初选定设备时(例如使用不成熟的驱动程序时),使用预定义(固定)的时钟和工作负载来测量每秒渲染的帧数 (fps)。这可以让我们清楚地了解硬件功能。
为了在规格设计阶段便于推究设备性能,可使用Flatland 工具。Flatland 依靠固定时钟,并显示可通过基于合成的工作负载实现的吞吐量。Flatland 使用 gralloc 缓冲区来模拟多窗口情景,用 GL 填充窗口,然后测量合成情况。
8909 vs 18xx测试结果分析:(提高GPU频率结果相当,因为GPU大部分情况是在高频跑的),可见8909仅适用于720P大小 ,而18xx可最大适用于1080P大小(尽管在SurfaceView->Home仍可能会有一点超时)。测试阶段为渲染,和合成无关,对于1881甚至必须关屏测试。
https://source.android.com/devices/graphics/implement
2. GPU合成评估本地测试:SurfaceComposition
绘制完成之后,我们也要考虑合成的情况,尽管我们一般采用HWC合成,但是GPU合成在某些场景下仍然是不可避免的。(但这一步的重要性低于flatten)
路径:android/frameworks/base/tests/SurfaceComposition
功能:测试保证在58fps以内的最大合成Surface的数量(格式可选)。
命令:手动打开应用测试或者使用cts测试方式
am instrument -w -r android.surfacecomposition/android.test.InstrumentationTestRunner
结果:
INSTRUMENTATION_STATUS: surface-allocation-performance-median-sps=112.55279399895551
INSTRUMENTATION_STATUS: surface-compoistion-bandwidth-gbps=0.9486905799147451
INSTRUMENTATION_STATUS: surface-compoistion-peformance-sps=4.7642438127286955
这次是测试通过的结果,代表可支持4.76层RGBA的合成(58fps以上),带宽0.94Gb/s
评估阶段结束,我们进入开发阶段。
3. OpenGLES 本地测试:fillrate、angeles、gl2_basic gl2_yuv
-
fillrate
比较简单,就是循环绘制draw的命令,迭代多次分别绘制1次,2次…32次的吞吐量,可测试GPU是否带起成功。
-
gl2_basic
非常简单,就是循环绘制一个三角形,60fps, Malit82x大约156M下46%的GPU利用率。因为负载比较均衡,因此可用于测试GPU功耗问题。
-
angeles
以50fps的帧率,malit82x下624M下81-90%的利用率。
负载不均衡,可在一定程度上进行压力测试,但没有deqp中压力测试效果好,因此其可以实现624M下GPU利用率99%-100%
-
gl2_yuv
另外一个常用case,可用于测试YUV数据显示于屏幕之上,NV12各种格式测试,这个场景应用非常多,我将在另外一篇文章中单独介绍。
4. GPU API测试工具(同时支持压力测试):DEQP
如果我们是OEM厂商,则我们同时还要关注GPU的兼容性与稳定性。这就需要Deqp模块了。(CTS也会测试相应API)
Deqp支持LINUX,WINDOW,ANDROID等平台,该文档仅介绍Android平台,具体可见下面链接:https://source.android.com/devices/graphics/testing
编译
目录:external/deqp
编译:mma –j12
环境准备:
安装APK:
adb –d install –r com.drawelements.deqp.apk
运行测试
-
准备:
adb –d forward tcp:50016 tcp:50016
adb –d shell am start –n com.drawelements.deqp/.execserver.ServiceStarter
-
执行测试:
1)测试全部GLES2的API
am start -n com.drawelements.deqp/android.app.NativeActivity -e cmdLine “deqp --deqp-case=dEQP-GLES2.* --deqp-log-filename=/sdcard/dEQP-Log.qpa --deqp-crashhandler=enable --deqp-watchdog=enable --deqp-gl-config-name=rgba8888d24s8”
2)压力测试:–deqp-test-iteration-count可以修改,GPU利用率可达99-100%
am start -n com.drawelements.deqp/android.app.NativeActivity -e cmdLine “deqp --deqp-case=dEQP-GLES2.stress.long.* --deqp-log-filename=/sdcard/dEQP-stress.qpa --deqp-watchdog=disable --deqp-gl-config-name=rgba8888d24s8 --deqp-test-iteration-count=500”
3)旋转屏幕测试
增加 --deqp-screen-rotation=90
结果分析
目前结果是文本文档,转换成csv或html格式需要编译linux或window版本。但仍然还可以分析一下结果。
• 通过可包括 Pass、NotSupported、QualityWarning 和 CompatibilityWarning。
• 失败可包括 Fail、ResourceError、Crash、Timeout 和 InternalError。
综上,如果你是OEM厂商,这些工具都会对你有帮助。如果你是终端厂商且GPU能力较强,则只有第3个工具对你有用,毕竟其他你也不用关心,如果GPU能力差些,则1, 2,3都会对你有所帮助。