GPU Performance

In the graphics department we're matching up Qualcomm's Adreno 420 versus the Mali T760MP6. The Adreno is running at 600MHz and is able to benefit from almost double the memory bandwidth at 25.6GB/s versus 13.2GB/s due to the Snapdragon's increased 128-bit memory interface. Let's look at how both compare in our overall benchmarks:

3DMark 1.2 Unlimited - Graphics

3DMark 1.2 Unlimited - Physics

3DMark 1.2 Unlimited - Overall

In 3DMark Unlimited the Exynos version comes just short of a few fps behind the Adreno 420. What is also surprising is that the Exynos 5433 performs much better in the physics score than I had anticipated; the same test on Huawei's SoCs limited the thread onto the little cores in the default settings giving mediocre performance results. However, it seems the A53 is performing much better and is able to match Qualcomm's offering now.

BaseMark X 1.1 - Dunes (High Quality, Offscreen)

BaseMark X 1.1 - Hangar (High Quality, Offscreen)

BaseMark X 1.1 - Dunes (High Quality, Onscreen)

BaseMark X 1.1 - Hangar (High Quality, Onscreen)

In BaseMark X 1.1, the Exynos is again neck-and-neck with the Snapdragon version. It loses by a slight margin in the Dunes benchmark while winning in the Hangar scenes by a similarly small margin. BaseMark X is again one of the benchmarks that can trigger the 700MHz state of the Mali GPU, offering higher performance at a much higher power draw depending on which scene is currently rendered on both tests.

GFXBench 3.0 Manhattan (Onscreen)

GFXBench 3.0 Manhattan (Offscreen)

GFXBench 3.0 T-Rex HD (Onscreen)

GFXBench 3.0 T-Rex HD (Offscreen)

Again we continue to see the same pattern in GFXBench's scenario benchmarks, with the Exynos version lagging a few frames behind the Qualcomm GPU in both Manhattan and T-Rex, in both on-screen and off-screen results.

GFXBench 3.0 ALU Test (Onscreen)

GFXBench 3.0 ALU Test (Offscreen)

It's on the synthetic tests that we finally see some major deviation between the two architectures. ARM's Mali simply can't seem to keep up with the ALU throughput of Qualcomm's architecture. Both the Adreno 330 and 420 have a clear computational power advantage, exceeding even Imagination's PowerVR GPUs in the iPhones, leaving Mali strictly on the lower end of the performance spectrum.

GFXBench 3.0 Alpha Blending Test (Onscreen)

GFXBench 3.0 Alpha Blending Test (Offscreen)

GFXBench 3.0 Fill Rate Test (Onscreen)

GFXBench 3.0 Fill Rate Test (Offscreen)

We see a similar situation in the Alpha Blending and Fillrate tests, as the Adreno offers 2-3x the throughput. Utilizing the extra memory bandwidth here seems to be key to the success of the Snapdragon 805's graphics performance.

GFXBench 3.0 Driver Overhead Test (Onscreen)

GFXBench 3.0 Driver Overhead Test (Offscreen)

I've already mentioned the Driver Overhead score in the the more in-depth analysis of the T760. It's the first Android device to truly stand out from the rest of the crowd, finally making some progress into trying to catch up with Apple's excellent performance on iOS. Here's hoping more vendors concentrate on improving this metric in future driver updates.

I did some extensive power measurements on the Note 4 Exynos in this review, so naturally we're keen to see how this transforms into our battery benchmarks on the next page.

CPU and System Performance Battery Life & Charge Time
Comments Locked

135 Comments

View All Comments

  • aryonoco - Wednesday, February 11, 2015 - link

    Everyone is aware that developing a power-aware scheduler is a VERY hard problem. The Linux kernel doesn't have it, but neither does anyone else really.

    The problem is that when ARM developed big.LITTLE, they would have known that for it to work, it requires a well-designed power-aware scheduler. And they should have known that that's a very hard problem to solve in software. History is littered with great hardware architectures that should have performed a lot better, if only the software was up to it, e.g., Intel's Itanium or Transmeta's Crusoe. But history has time and time shown that architectures that require too clever a software solution around them just don't work (perhaps one should add AMD's Bulldozer to this list as well, seeming as AMD expected everyone to rewrite their software to become GPU aware).

    I remember back in the days KISS was a big mantra of Unix sysadmins, and for a good reason: you can optimize simple things very well. Witness the simple (by comparison) dual core Apple A8 that doesn't require any magical scheduler or a binary translator (Denver) and yet beats everyone else in practical tests. It's disheartening that the likes of ARM and Nvidia don't seem to have learnt this.
  • tuxRoller - Thursday, February 12, 2015 - link

    The article suggests that this (the scheduler) is work that Samsung (alone) should've done. I don't recall the author indicating that it's actually an unsolved problem in computer science (again, in a general purpose environment), as I indicated, BTW.
    big.LITTLE will certainly work best with such a scheduler, but even without you should expect to approach some efficiency that lies between the big and little cores. Even this half-hearted attempt isn't terribly worse than the android competition.
  • Andrei Frumusanu - Thursday, February 12, 2015 - link

    Power collapse is proper power gating on the individual cores in their respective CPUIdle states, your link is outdated and does not apply to new generation ARM cores.
  • tuxRoller - Thursday, February 12, 2015 - link

    Do you have a reference?
    To the best of my knowledge linaro are still working on hotplug.
    Also, for Linux, cpuidle refers to a specific governor that doesn't actually power down, but handles the c states, but it looks like arm uses it for suspension (http://events.linuxfoundation.org/sites/events/fil... slides 10 and 13).
  • Andrei Frumusanu - Friday, February 13, 2015 - link

    CPUIdle is the kernel framework that manages the CPU's idle states, such as WFI (Clock gating), core power collapse, cluster power collapse. CPUIdle states are C-states, but "C-states" is an ACPI denomination that is rarely used on ARM CPUs.

    Hotplug has been left for dead for a long time, it hasn't been used for PM in ARM CPUs since the A15/A7 generation. Today it's only used for like forcing cores off when in screen-off states or rare coarse power management for like battery savings modes for some vendors.
  • sgmuser - Thursday, February 12, 2015 - link


    I have Exynos and wanted that specifically for the Wolfson Audio. Sad to note that, its not exploited enough by Samsung.

    Did someone notice the RAM bandwidth. How much impact that it makes?
    Also, from personal experience, I find exynos seems to be smooth and never noticed lag for an user like me. Graphics performance could be better but again no visible issues for what I have been playing so far with such dense display.
  • giaf - Saturday, February 14, 2015 - link

    Very interesting and detailed article, thank you.

    I have been working with ARMv7A cores, and I am interested in the floating-point capabilities of new 64-bit ARM processors. What is the throughput of the main floating-point instructions (add, mul, MAC) for Cortex A53 and A57? Something similar to the test done in http://www.anandtech.com/show/6971/exploring-the-f...
  • thegeneral2010 - Wednesday, February 18, 2015 - link

    i just dont get it wat do u mean by "however it remains unclear whether we'll see this on the Note 4. My personal opinion remains that we won't be seeing this overhaul in Samsung's 5.0 Lollipop update." does this mean that exynos 5433 could be upgraded to 64bit on android 5.1 or later updates??
  • Andrei Frumusanu - Friday, February 20, 2015 - link

    At the time of the writing the Lolipop update was not yet released. Now it's out and it's not 64bit as I suspected. If they didn't update it now they won't ever update it and it will stay on AArch32.
  • thegeneral2010 - Sunday, February 22, 2015 - link

    so wat about that official patches in upstream linux?

Log in

Don't have an account? Sign up now