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

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

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

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

我们的最初产品是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 ES在以下情况下突出显示驱动程序错误和问题：

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

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