Android图像驱动的故事：ARM vs. Qualcomm

Hugues Evrard,Paul Thomson 和我最近成立了一家专业的自动化图形驱动测试公司——GraphicsFuzz。该公司是我们去年在伦敦帝国学院（Imperial College London）一系列研究成果的产物。

我们最初的产品是ShaderTest GLES，一套GPU开发者可以用于测试OpenGL ES驱动器可靠性的片段着色器。

本文是我们通过运行具有代表性样本的着色器，来探究Android OpenGL ES 驱动可靠性系列文章的第一部分。

您还可以通过GraphicsFuzz Android基准测试在Android设备上体验这些着色器。

ShaderTest GLES：测试着色编译器的质量

我们从对背景色的渲染来开始测试，如果你等不及，可以跳过这部分。

传统的GPU测试模块专注于渲染速度或是API 功能的完备性。ShaderTest GLES 将另一度量维度—— 着色编译质量 加入测试中。毕竟，如果渲染出错，速度再快也用处不大！(原译文：“这意味着，优秀的渲染速度并不意味着良好的渲染效果如果渲染出错！”语序不当，已修正 -- 译者注)

与工业界的软件工程师交谈中，我们经常听到GPU驱动开发工程师优先在知名游戏和app——例如Google Play Store上top 100游戏上测试他们的产品。由此导致的不良影响是那些不太受欢迎的应用的开发者必须自个儿解决有关驱动的bug来使他们的app能在用户的设备上正确地运行起来。 同时由于Android系统向用户终端推送更新的速度烂的出奇，这就造成了一种循环现象：GPU驱动bugs一直得不到重视。一是主流的游戏都运行良好 （总有一种方法可以暂时处理这个问题）；二是若想要该APP能够继续使用，无论如何，你都得解决这个问题，因此不值得去专门报告此漏洞。 （注 此处翻译不当，已修改！原文： “同时由于Android系统向用户终端推送更新的速度烂的出奇，这就造成了一种自我延续效应，GPU驱动bugs并不会被视为一个严重的问题因为主流的游戏都能很好的运行；并且要使应用软件运行，应用开发者必须自己解决问题，因此报告也无济于事。”） 这也使得开发者很难开发处优秀的着色器：只有驱动质量条件改善了，它才可能在一系列的设备上运行。

ShaderTest GLES 方法

（有关着色器和着色编译器的背景知识，请阅读此文 https://medium.com/@afd_icl/crashes-hangs-and-crazy-images-by-adding-zero-689d15ce922b

ShaderTest GLES 由众多的着色器家族组成，每个系列都包含一个用于渲染单帧参考着色器，以及为数众多的变种着色器——用来渲染视觉上与参考帧相同的帧，不过却是以完全不同的方式实现的。

变种着色器是以保留语义的变换（即在不影响渲染效果的前提下变换参考着色器的源代码）的方式从参考着色器获取相关参数。举例来说，就如同把参考着色器代码块转换成循环的形式：

 for（int i = 0; i <1; i ++）{
  //参考着色器的原始代码
}

以上是一个简单例子。

                                                            图：ShaderTest GLES通过区分图片渲染中的不匹配问题、错误和渲染崩溃等问题，来找出图形驱动中的bug

ShaderTest ES 重点关注些bug和问题：

• ·变种编译器被着色编译器拒绝——编译失败；

• ·变种编译器致使驱动的某些部件崩溃——渲染崩溃；

• ·变种着色器渲染出的图片与参考图片有肉眼可见的误差——渲染错误；

• ·由于时间或内存限制导致驱动程序退出——资源占用问题；

编译失败和渲染崩溃通常意味着bug。渲染错误通常是由miscompilation 所致，此时着色编译器产生错误的代码；有时图形系统中的浮点灵敏度也可能产生同样的问题。对于上述两种成因的问题，ShaderTest GLES都能检测出来。我们在此处最大进步便是：miscompilations触发的渲染错误问题以传统的技术手段非常难以检测。资源占用问题让我们洞悉了图像驱动在非功能方面的限制。

以三星设备为例

 让我们用目前市面上人气最高的Android设备三星Galaxy S8来验证我们的结果。根据地域的不同，S8配备的GPU可分为ARM系列与QualcommGPU，所以让我们来看看它们的性能如何。

我们网站上给出了ARM和QualcommS8在10种着色器系列上的测试结果。

                                                                           图：ARM GPU与QualcommS8比较结果的截图

比较ARM 和QualcommGPU结果可知，ARM GPU看起来更加可靠。但是我们还是发现了以下问题：

渲染问题

QualcommGPU存在更多的渲染问题：相较ARM ，其在测试中存在的问题更多5个。

例如，以着色器001系列的测试结果为例，除了渲染崩溃外，ARM总是得到与参考图像一致的渲染结果：                                                                                                      

                                               图：着色器系列001的参考图像，所有的变种着色器都应当得到相似的结果。

QualcommGPU在大体上能得到良好的结果，不过却有一组图像存在明显错误；

                                           图 ：QualcommGPU上，我们得到的理想结果如左图，中图和右图为渲染错误图像，这大概是着色编译器bug。

着色编译器系列001的参考着色器并不是浮点数敏感的，这些差异导致的渲染错误与由于着色编译器bug产生的误差相似。

我们也观察到ARM的渲染错误问题，比如着色器系列007的变种着色器77：

                                   图：着色器007系列的参考图像（左图），ARM S8渲染出错的图像（右图）。

不确定性问题

我们的测试结果显示了QualcommGPU存在的两个不确定性问题：有时是着色编译器在编译期间崩溃；有时是编译成功但却渲染出错误的图像。这种情况在着色器007系列的变种着色器123和着色器008系列的变种着色器51上出现。

                                 图：每组图片包括一张理想图像以及一张经过QualcommGPU渲染的坏的图像。

渲染崩溃

这两种图形驱动在渲染图像样本时都存在为数不少的崩溃问题：Qualcomm的28 vs ARM的15个。这些都是编译时段错误——致命信号11（SIGSEGV）。

有趣的是，在渲染着色器006系列的34变种着色器时，这两类图形驱动都不可避免的崩溃了。然而，正如我们在后续的文章所见，其他图形驱动却可以很好的解决该问题。

编译失败

ARM的图形驱动存在一个编译失败问题——在处理着色器003系列的216变种着色器。该问题是由于对三元运算符（？：）的处理不当造成的。QualcommGPU存在更多的编译失败问题，包括编译器和连接器的错误，一共9个。尽管其中有些错误似乎是由于与处理switch语句有关的单个基础问题引起的。

资源占用问题

我们的测试结果并没有发现针对QualcommGPU的资源占用问题，但是ARM在渲染着色器003 系列的122变种着色器时，却反馈了一个GL_OUT_OF_MEMORY错误。

如若想查看S8 vs. S8的完整的结果，请访问这个页面：

原文：https://medium.com/@afd_icl/a-tale-of-two-samsungs-arm-vs-qualcomm-in-android-graphics-c1c6f1eef828

                                                                                                                                                                                    译/ 看雪翻译小组 StrokMitream

[培训]内核驱动高级班，冲击BAT一流互联网大厂工 作，每周日13:00-18:00直播授课