两个三星的故事：Android图形中的ARM与高通

比较ARM和Qualcomm Android图形驱动程序S8至S8的可靠性

另请参阅&＃xff1a;后续帖子评估&＃xff1a;

• NVIDIA防护罩
• Google Pixel设备

Hugues Evrard&＃xff0c;Paul Thomson和我最近成立了GraphicsFuzz公司&＃xff0c;专门从事图形驱动程序的自动化测试。 该公司是伦敦帝国理工学院研究的成果&＃xff0c;我们去年通过一系列中等故事对它进行了描述。

我们的最初产品是ShaderTest GLES &＃xff0c;这是一大套片段着色器套件&＃xff0c;GPU设计人员可以授权它们使用它们&＃xff0c;以全面测试OpenGL ES驱动程序的可靠性。

这是一系列故事中的第一篇&＃xff0c;我们将通过在ShaderTest GLES着色器的代表性示例上运行它们来判断Android OpenGL ES驱动程序的可靠性。

您还可以通过GraphicsFuzz Android基准测试在Android设备上尝试选择这些着色器-在浏览器中尝试使用网络应用程序&＃xff0c;让我们知道您所找到的内容&＃xff01;

ShaderTest GLES&＃xff1a;测试着色器编译器质量

我们将从ShaderTest GLES的一些背景开始&＃xff0c;但是如果您不耐烦&＃xff0c;可以跳到结果 &＃xff01;

传统的GPU测试套件专注于渲染速度或API功能完整性。 ShaderTest GLES通过测试着色器编译器质量 &＃xff0c;为故事添加了另一个维度。 毕竟&＃xff0c;如果错误的话&＃xff0c;快速渲染结果可能并不是特别有用&＃xff01;

与行业中的软件工程师交谈&＃xff0c;我们一次又一次听到GPU驱动程序开发人员优先考虑针对知名游戏和应用&＃xff08;例如Google Play商店中排名前100的游戏&＃xff09;测试其驱动程序。 不幸的是&＃xff0c;不那么受欢迎的应用程序的开发人员必须解决驱动程序错误&＃xff0c;才能使其应用程序在消费类设备上运行。 再加上将Android更新推送给最终用户的速度缓慢&＃xff0c;这造成了一种自我延续的局面&＃xff0c;由于流行的游戏运行良好&＃xff08;可能使用了解决方法&＃xff09;&＃xff0c;GPU驱动程序错误并未被视为严重问题&＃xff0c;而GPU驱动程序错误并未被视为严重问题。值得报告&＃xff0c;因为如果您希望消费者能够使用您的应用&＃xff0c;则无论如何都必须解决这些错误。 这也阻止开发人员编写有趣的着色器&＃xff1a;在驱动程序质量状况改善之前&＃xff0c;他们不太可能在多种设备上工作。

ShaderTest GLES方法

&＃xff08; 有关着色器和着色器编译器的一些背景&＃xff0c;请参阅此文章 。&＃xff09;

ShaderTest GLES由许多着色器系列组成 。 每个家庭包含一个参考 着色器用于呈现单个帧&＃xff0c;和几百变体着色器设计成呈现视觉上相同帧到参考&＃xff0c;但行使驱动器在过程完全不同的方式。

通过应用保留语义的转换&＃xff08;即不影响渲染结果的对参考着色器源代码的转换&＃xff09;&＃xff0c;可以从参考着色器中获取变体着色器。 例如&＃xff0c;以以下形式的循环将代码块包装在参考着色器中&＃xff1a;

是保留语义的转换的简单示例。

ShaderTest ES在以下情况下突出显示驱动程序错误和问题&＃xff1a;

• 变体着色器被驱动程序的着色器编译器拒绝 - 编译失败 &＃xff1b;
• 变体着色器导致驱动程序的某些组件崩溃 — 崩溃错误 &＃xff1b;
• 与参考着色器相比&＃xff0c;变体着色器导致渲染的图像明显不同— 渲染问题 &＃xff1b;
• 变体着色器会由于时间或内存限制&＃xff08; 资源问题&＃xff09;而导致驱动程序无法使用。

编译失败和崩溃错误始终表示错误。 通常呈现问题 的出现是由于miscompilation错误&＃xff0c;由此着色器编译器产生错误的代码; 由于图形系统中的浮点敏感性&＃xff0c;它们有时也会表现出来— ShaderTest GLES可以阐明这两个问题。 这里的一大胜利是&＃xff0c;引发渲染问题的错误编译非常难以检测&＃xff0c;因此常常逃避传统的测试技术。 资源问题提供了对图形驱动程序非功能性约束的见解。

为了三星&＃xff01;

首先&＃xff0c;我们将比较参考着色器和变体着色器与市场上最流行的Android设备之一&＃xff1a;三星Galaxy S8手机的结果。 根据地区的不同&＃xff0c;S8附带了ARM或Qualcomm GPU&＃xff0c;因此让我们看看这些GPU设计人员的驱动程序是如何运作的。

我们的GraphicsFuzz网站显示了10个着色器系列中ARM和Qualcomm S8型号之间的比较 。

比较ARM和Qualcomm GPU驱动程序之间的结果-从现在起&＃xff0c;我们将它们简单地称为“ ARM”和“ Qualcomm”-ARM模型看起来更可靠。 我们发现以下问题&＃xff1a;

渲染问题

高通公司面临着更多的渲染问题 &＃xff1a; 我们的表格显示了高通公司的五个渲染问题&＃xff0c;而ARM的情况则是五个。

例如&＃xff0c; 检查着色器系列001的结果 。 除了崩溃之外&＃xff0c;ARM普遍渲染参考图像&＃xff1a;

而使用Qualcomm&＃xff0c;我们可以获得大多数变体的参考图像&＃xff0c;但混合图像中也有一些错误图像&＃xff1a;

着色器系列001着色器的参考着色器不是浮点敏感的&＃xff0c;因此这些差异很可能对应于着色器编译器错误。

对于着色器系列007的变体77&＃xff0c;我们还观察到一个ARM渲染问题&＃xff1a;

非确定性

我们的测试揭示了高通公司的两个问题&＃xff0c;其中驱动程序的行为不确定&＃xff1a;有时着色器编译器在编译过程中崩溃&＃xff1b; 其他时候编译成功并且渲染了错误的图像。 对于着色器系列007的变体123和着色 器系列008的变体51会发生这种情况。

崩溃错误

这两个驱动程序在我们的示例中都发生了很多崩溃&＃xff1a;高通公司的崩溃为28&＃xff0c;ARM公司的崩溃为15。 所有都是编译时分段错误-致命信号11&＃xff08;SIGSEGV&＃xff09;。 Android上提供的崩溃数据并没有提供与这些崩溃原因相关的任何信息。

有趣的是&＃xff0c;两个驱动程序都不能处理着色器系列006的变体34而不会崩溃。 但是&＃xff0c;正如我们将在以后的文章中看到的那样&＃xff0c;其他图形驱动程序也可以处理此变体。

编译失败

ARM驱动程序表现出一个编译器故障&＃xff0c;这种情况发生在着色器系列003的变体216中。 该问题似乎与三元运算符&＃xff08;&＃xff1f;:)的处理不当有关。 Qualcomm显示出更多的编译器故障-总计9个&＃xff08;合并编译器和链接器错误&＃xff09;&＃xff0c;尽管其中一些错误似乎是由于与switch语句处理相关的一个基本问题所致。

资源问题

我们的结果没有突出显示任何Qualcomm资源问题&＃xff0c;但确实显示了着色器系列003的变体122上ARM的资源问题&＃xff0c;该着色器在渲染过程中提供了GL_OUT_OF_MEMORY。

查看完整的S8与S8结果表 &＃xff0c;并尝试使用GraphicsFuzz Android基准测试Web应用程序 &＃xff01;

下次…

… 我们将了解NVIDIA Shield TV的Android驱动程序如何运行 。

From: https://hackernoon.com/a-tale-of-two-samsungs-arm-vs-qualcomm-in-android-graphics-c1c6f1eef828