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

高通骁龙845 arm

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

GraphicsFuzz ShaderTest GLES测试套件揭示了三星Galaxy S8上的各种图形驱动程序问题。与ARM GPU模型相比，Qualcomm GPU模型遭受的渲染问题和崩溃多得多。跳到我们对结果的分析。

另请参阅：后续帖子评估：

NVIDIA防护罩
Google Pixel设备

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

单击上方以试用我们的GraphicsFuzz Android基准测试网络应用程序。

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

这是一系列故事的第一篇，我们将通过在代表性的ShaderTest GLES着色器样本上运行来判断Android OpenGL ES驱动程序的可靠性。

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

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

我们将从ShaderTest GLES的一些背景开始，但是如果您不耐烦，可以跳到结果！

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

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

ShaderTest GLES方法

（有关着色器和着色器编译器的一些背景，请参阅此文章。）

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

变体着色器是通过应用保留语义的转换 （从参考着色器获得的，即不影响渲染结果的对参考着色器源代码的转换）而获得的。例如，以以下形式的循环将代码块包装在参考着色器中：

for (int i = 0; i < 1; i++) {  // original code from reference shader}

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

ShaderTest GLES通过识别等效着色器系列之间的渲染不匹配，错误和崩溃来发现图形驱动程序中的错误。

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

变体着色器被驱动程序的着色器编译器拒绝 - 编译失败 ；
变体着色器导致驱动程序的某些组件崩溃 — 崩溃错误 ；
与参考着色器相比，变体着色器导致渲染的图像明显不同— 渲染问题 ；
变体着色器由于时间或内存限制（ 资源问题）而导致驱动程序无法正常运行。

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

为了三星！

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

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

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

渲染问题

高通公司面临着更多的渲染问题 ：我们的表格显示了高通公司的五个渲染问题，而ARM中的一个。

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

虽然使用Qualcomm，我们可以获得大多数变体的参考图像，但混合图像中也有一些错误图像：

在Qualcomm上，我们获得了着色器系列001中大多数变体的预期图像（左），但可能是由于着色器编译器错误而导致了两个错误图像（中右）。

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

对于着色器系列007的变体77，我们还观察到一个ARM渲染问题：

着色器系列007 （左）的参考图像与ARM S8上变体77（右）呈现的不良图像相比。

非确定性

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

每对包括一个预期的参考图像（成对的左侧图像）和高通渲染的不良变体图像（成对的右侧图像）。但是，Qualcomm驱动程序在生成此错误图像与在编译期间崩溃之间不确定地波动。

崩溃错误

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

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

编译失败

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

资源问题

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

查看完整的S8与S8结果表，并尝试使用GraphicsFuzz Android基准测试Web应用程序！

下次…

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

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

高通骁龙845 arm