The Fastest GPU in a Smartphone

One thing I’ve learned over the past several years is that if you’re not the original manufacturer of something and are simply a glorified parts assembler, you generally have no clue how to do something right. There are obvious exceptions (Apple appears to be doing well), but this characterization applies to a lot of companies in the consumer electronics industry. They buy chips and parts from various suppliers, do a little bit of industrial design and generally don’t have the engineering know-how to deliver an optimized product into the marketplace.

Samsung is quite the opposite. Samsung is a DRAM manufacturer, a NAND flash manufacturer, and an application processor manufacturer. Samsung is responsible for the DRAM, NAND and silicon that goes into every iOS device sold by Apple. The company knows a thing or two about engineering.

The SoC inside the Epic 4G and other Galaxy S parts is called Hummingbird. It’s a 45nm SoC that implements a standard ARM Cortex A8 running at 1GHz and a PowerVR SGX 540 GPU. Despite Samsung’s experience in silicon manufacturing, it’s not much of an architecture/design company so we do see a lot of IP licensing within Hummingbird.

In this capacity Samsung is no different than TI, but what really sets Hummingbird apart is its GPU. Licensed from Imagination Technologies, the PowerVR SGX 540 is a significant improvement over the 530/535 in use in the iPhone, iPad and Motorola’s Droid X.

The SGX 530 has two USSE pipes and a single texturing unit. The 535 adds a second texturing unit, and the 540 adds another two USSE pipes. It’s unclear what clock speed the SGX 540 runs at inside Hummingbird, but I’d expect it’s somewhere near the 200MHz of the 535 in TI’s OMAP 3630.


Quake 3 Arena running on the PowerVR SGX 540

The added execution hardware does incur a power penalty, however Imagination lists it as less than double the SGX 535.

The performance improvement is tangible. Samsung’s Hummingbird faster in 3D games/apps than any other SoC used in a smartphone today:

Under Quake III we saw a 44.5% increase in performance over the Droid X. Compared to Qualcomm's Snapdragon, performance improves by nearly 2x.

Even in Qualcomm's own 3D test, the PowerVR SGX 540 is more than twice as fast as the Snapdragon. We see a 30% performance advantage over the OMAP 3630. I'd expect to see about the same advantage over Apple's A4.

Unfortunately for Samsung, 3D gaming hasn’t really taken off on Android as a platform. The best examples of what’s to come are what we’ve seen from Epic and id, but both of those demos were done on iOS (although I suspect Android versions would hit at some point) and we’re still pretty far away from having actual games based on those engines on mobile phones.

While the SGX 540 could be responsible for the Epic 4G’s smoother than expected UI, it’s mostly a waste of hardware today. Clearly you don’t need this powerful of a GPU to make scrolling through menus smooth. Perhaps Samsung has grand plans for Hummingbird or simply wanted to outdo the competition on paper. Higher resolution products due out in the future will demand faster GPUs (think tablets) so it’s possible that Hummingbird wasn’t specifically targeted for an 800 x 480 smartphone.

General CPU performance is comparable to the OMAP 3630 and what you’d expect from a 1GHz Cortex A8. The 45nm SoC should sip power but it’s unclear what Samsung is doing for power management on the SoC itself. While both Hummingbird and Apple’s A4 are manufactured at the same fab at 45nm and both use the Cortex A8, there’s a lot more to determine the total power consumption of an SoC.

Hummingbird’s memory bus is likely a 32-bit single channel LPDDR1 interface, but overall I’d say it’s safe to say that this is the fastest SoC currently shipping in a smartphone. Apple’s A4 used in the iPhone doesn’t run at 1GHz, and TI’s OMAP3630 uses the PowerVR SGX 530 compared to Samsung’s SGX 540. Unfortunately much of the performance advantage will go unused as 3D gaming simply isn’t that prevalent on Android phones today.

The Keyboards Cellular & WiFi Performance
POST A COMMENT

93 Comments

View All Comments

  • Ethaniel - Monday, September 06, 2010 - link

    I have also noticed that all Android phones out there do some kind of "breakdancing". You think it has something to do with Android, but I think it has something to do with Java. Now, Java devs will probably want to eat my brain after this... but Java sucks. Big time. Making Android's UI based on Java was a bad, bad, really bad move. About four three time slower than C++, it demands more memory... completely inadequate for a mobile environment. Reply
  • meatless - Monday, September 06, 2010 - link

    It's sad, the prevalence of Java FUD to this day. It's also bad to blame Java (the syntax), as you are unnecessarily conflating the Dalvik VM with desktop VMs such as Sun's.

    C++ is fast, sure, but there is a lot more to designing a platform than speed, and the Dalvik VM is more than fast enough. iOS's Obj-C implementation is also not C++ fast, but who complains?
    Reply
  • taltamir - Tuesday, September 07, 2010 - link

    1. both Javas are shit
    2. There is more to a platform then speed... but when you are designing a platform starved for processing power and that needs to sip electricity then it makes a huge difference.
    Reply
  • Penti - Tuesday, September 07, 2010 - link

    Most of the platform are actually C/C++ libraries and programs, where you glue your app in isn't that relevant. You need a framework for any mobile phone platform, but the resources that framework glues into thats where a lot of performance comes from and it's in C/C++. It's better to have an accelerated framework running on a virtual machine then an unaccelerated C++ one. Rendering of menus and such would be slower on the last one. Besides on Symbian it's QT-framework that rules now, not some ultra customized embedded framework. Memory requirements have gone up there too, but capacity have grown even more. Besides nobody wanted to write mobile apps to some badly designed and awkward C++ framework and API. Java syntax was a good choice therefor. Reply
  • taltamir - Monday, September 13, 2010 - link

    the fact that there are more considerations than just programming language when it comes to power and speed are obvious, as is that you could make a java app thats faster than a C++ app.
    Neither make java a good choice.

    BTW, I didn't personally comment about the issue of jerkiness, I was going on a tangent as a reply to what meatless said (specifically the socalled "java FUD")
    Reply
  • zizagoo - Monday, September 06, 2010 - link

    It's an Android problem. The cause of the "jerkiness" is that unlike iOS/WebOS/WP7, Android doesn't have a gpu accelerated ui. They supposedly did this because the G1 wouldn't support it at the time.

    http://code.google.com/p/android/issues/detail?id=...

    Gingerbread, which is supposedly showcased next month, should fix this.
    Reply
  • deputc26 - Monday, September 06, 2010 - link

    Thankyou! this is exactly it, give the man a medal. I don't know why Anandtech never mentions this. It should be ubiquitous knowledge in the android community. Reply
  • meatless - Monday, September 06, 2010 - link

    Also, the 3-4X speed difference on non-mobile platforms is greatly exaggerated. I always find http://shootout.alioth.debian.org/ a fun and FUD-free site. Reply
  • Iksy - Tuesday, September 07, 2010 - link

    Greatly exagerated? That site shows a 2.3x speed difference and it's comparring against Sun's fastest most optimizing version against g++. The unoptimized version is over 20x slower, you'll find it near the bottom of the list for compares. I do find it interesting that while they're satisfied with using an open source C (gnu) compiler, they do not include the open source java interpreter. They also do not include the Intel C compiler, even though they easily could and include the Intel Fortran compiler.

    In other words, is still in the ball park so say Java is 3-4x slower than the equivalent c++ code.
    Reply
  • dvinnen - Tuesday, September 07, 2010 - link

    Wait, so the Java syntax is what is slowing down Android? Because it doesn't run Java, it runs Dalvik.

    I would also like to see evidence that C++ is 4 times faster. Not saying Java is faster but it is fast enough. I say that as a Java developer who doesn't like the language and would rather use slower languages like Python
    Reply

Log in

Don't have an account? Sign up now