ARM GPUs in Huawei phones

Android OpenGL ES support is getting better!

Alastair Donaldson
4 min readFeb 15, 2018

Got an Android phone? Try the GraphicsFuzz benchmark for yourself, in your browser!

In our series of posts about GraphicsFuzz and ShaderTest GLES, we have looked so far at one ARM GPU: the Mali G71 featured in some Samsung Galaxy S8 phones.

Let’s now take a look at results from ShaderTest on three Huawei Honor phones that feature ARM GPUs:

  • Honor 9 — ARM Mali G71
  • Honor 9 lite — ARM Mali-T830
  • Honor 10 — ARM Mali G72

The Honor 9 and Galaxy S8 use the same ARM Mali G71 GPU design, yet are integrated into different SoCs: the S8 uses a Samsung Exynos chipset, while the Honor 9 uses a HiSilcon KIRIN chipset.

Spoiler

From our test results it looks like ARM are doing pretty well with shader compiler quality, compared with the competition: Qualcomm, NVIDIA and Imagination do not fare so well! But it would be nice to see the bug rate on our tests go to zero!

See the result tables in full.

Background

If you’re not yet familiar with how our testing works then check out this overview.

Honor 10 tops the reliability table

Summary of test results for a sample of 150 ShaderTest GLES tests. Our results page provides a more detailed table.

The ARM driver in our Honor 10 phone appears to be pretty good when it comes to fragment shaders!

ShaderTest GLES has 3000 tests, and we’re showcasing results for 150 of them in these posts. Running these 150 tests on the Honor 10 we find 9 crashes and 1 compile failure, but that is all. Notably, the Honor 10 does not trigger any rendering issues on these tests. Good job!

As an example of one of the segfault crashes, the logs show that the issue comes from a problem in ARM’s driver (libGLES_mali.so) related to dominator trees:

#00 pc 000000000099ef40 /vendor/lib64/egl/libGLES_mali.so (walk_domtree+4)

Honor 9? Not so much

The results are very different when we look at the Honor 9.

This Huawei phone has the same GPU as in the Galaxy S8, but in a different chipset and with different drivers.

  • Honor 9: driver version v1.r2p0–02dev0. The “dev” part of this name suggests that it might be a development driver.
  • Galaxy S8: driver version v1.r3p0–00rel0. The “rel” suggests that this is a release driver.

Presumably the S8 driver is also a bit newer — r3 vs. r2.

The difference shows!

We see 12 rendering issues on the Honor 9 across the 150 tests, compared with just 1 issue for the Galaxy S8. Here are some examples where, within a single shader family, the Honor 9 yields at least two wrong images:

For shader families 005, 006 and 008 the Honor 9 exhibits multiple, different, rendering issues. The reference images (left) are expected, but for some variants wrong images (middle and right) are computed.

The number of crashes across our tests for the Honor 9 and the Galaxy S8 is the same — 15 crashes across the 150 tests, significantly higher than the crash rate for the Honor 10.

The problems in this older GPU driver underline the problem of driver lag, whereby many Android devices don’t get the latest updates from GPU vendors.

Honor 9 lite — Reliable? Yes. Efficient? Less clear.

In contrast to the Honor 9, our results for the Honor 9 lite are pretty good — in some cases they improve on the Honor 10. In particular, the crash rate is reduced from 9 to 3 — e.g. the Honor 10 crashes on variant 066 from shader family 002 and variant 177 from shader family 003, but the Honor 9 lite renders these just fine.

There are still some crashes though; including one that gives this cryptic message:

E MemoryLeakMonitorManager: MemoryLeakMonitor.jar is not exist!
E Minikin : Could not get cmap table size!

We see one rendering issue with the Honor 9 lite, which the ARM Galaxy S8 also suffers from:

The reference image for shader family 007 is shown on the left. On the Honor 9 lite and Galaxy S8, with ARM GPU drivers, the wrong image on the right is rendered for variant 077 of this family.

Despite its relative reliability, the Honor 9 lite drivers show some potential performance issues: we see 4 timeouts and 2 memouts. For example, variant 039 from shader family 003 times out during compilation (timeout limit: 30 seconds), variant 122 from shader family 003 times out during rendering (timeout limit: 30 seconds again), and variant 062 from shader family 010 fails due to memory exhaustion during rendering.

Although our tests are designed to assess reliability, not performance, the tests could be useful to ARM and Huawei to aid in optimizing this driver.

Summary

It’s great to see that — at least according to the latest ShaderTest results — recent ARM Mali drivers are getting more reliable. Hopefully good testing processes at ARM will ensure that this doesn’t slip, and better testing processes at competitors will close the gap. Of course, ShaderTest GLES can help with both!

Try the benchmark!

Did you try out the GraphicsFuzz Android benchmark in your web browser?

Next time

We’ll look at ShaderTest results on some Apple iPhones.

--

--