The MSM8960 is an unusual member of the Krait family in that it doesn't use an Adreno 3xx GPU. In order to get the SoC out quickly, Qualcomm paired the two Krait cores in the 8960 with a tried and true GPU design: the Adreno 225. Adreno 225 itself hasn't been used in any prior Qualcomm SoC, but it is very closely related to the Adreno 220 used in the Snapdragon S3 that we've seen in a number of recent handsets.

Compared to Adreno 220, 225 primarily adds support for Direct3D 9_3 (which includes features like multiple render targets). The resulting impact on die area is around 5% and required several months of work on Qualcomm's part.

From a compute standpoint however, Adreno 225 looks identical to Adreno 220. The big difference is thanks to the 8690's 28nm manufacturing process, Adreno 225 can now run at up to 400MHz compared to 266MHz in Adreno 220 designs. A 50% increase in GPU clock frequency combined with a doubling in memory bandwidth compared to Snapdragon S3 gives the Adreno 225 a sizable advantage over its predecessor.

Mobile SoC GPU Comparison

Adreno 225

PowerVR SGX 540

PowerVR SGX 543

PowerVR SGX 543MP2

Mali-400 MP4

GeForce ULP

Kal-El GeForce

SIMD Name

-

USSE

USSE2

USSE2

Core

Core

Core

# of SIMDs

8

4

4

8

4 + 1

8

12

MADs per SIMD

4

2

4

4

4 / 2

1

1

Total MADs

32

8

16

32

18

8

12

GFLOPS @ 200MHz

12.8 GFLOPS

3.2 GFLOPS

6.4 GFLOPS

12.8 GFLOPS

7.2 GFLOPS

3.2 GFLOPS

4.8 GFLOPS

GFLOPS @ 300MHz

19.2 GFLOPS

4.8 GFLOPS

9.6 GFLOPS

19.2 GFLOPS

10.8 GFLOPS

4.8 GFLOPS

7.2 GFLOPS

We turn to GLBenchmark and Basemark ES 2.0 V1 to measure the Adreno 225's performance:

Limited by Vsync the Adreno 225 can actually deliver similar performance to the PowerVR SGX 543MP2 in Apple's A5. However if we drive up the resolution, avoid vsync entirely and look at 720p results the Adreno 225 falls short. Its performance is measurably better than anything else available on the Android side in the Egypt benchmark, however the older Pro test still shows the SGS2's Mali-400 implementation as quicker. The eventual move to Adreno 3xx GPUs will likely help address this gap.

Basemark ES 2.0 tells a similar story (updated: notes below):

In the original version of this article we noticed some odd behavior on the part of the Mali-400 MP4 based Samsung Galaxy S 2. Initially we thought the ARM based GPU was simply faster than the Adreno 225 implementation in the MSM8960, however it turns out there was another factor at play. The original version of Basemark ES 2.0 V1 had anti-aliasing enabled and requested 4X MSAA from all devices that ran it. Some GPUs will run the test with AA disabled for various reasons (e.g. some don't technically support 4X MSAA), while others (Adreno family included) will run with it enabled. This resulted in the Adreno GPUs being unfairly penalized. We've since re-run all of the numbers with AA disabled and at WVGA (to avoid hitting vsync on many of the devices).

Basemark clearly favors Qualcomm's Adreno architecture, whether or not that's representative of real world workloads is another discussion entirely.

The results above are at 800 x 480. We're unable to force display resolution on the iOS version of Basemark so we've got a native resolution comparison below:

RightWare Basemark ES 2.0 V1 Comparison (Native Resolution)

Taiji

Hoverjet

Apple iPhone 4S (960 x 640)

16.623 fps

30.178 fps

Qualcomm MDP MSM8960 (1024 x 600)

40.576 fps

59.586 fps

Even at its lower native resolution, Apple's iPhone 4S is unable to outperform the MSM8960 based MDP here. It's unclear why there's such a drastic reversal in standing between the Adreno 225 and PowerVR SGX 543MP2 compared to the GLBenchmark results. Needless to say, 3D performance can easily vary depending on the workload. We're still in dire need of good 3D game benchmarks on Android. Here's hoping that some cross platform iOS/Android game developers using Epic's UDK will expose frame rate counters/benchmarking tools in their games.

There are some hickups in Android that have to do with the UI thread looking up storage but for the most part, it's a CPU thing. The thing to keep in mind is that UI fluidity is an entirely different type of code than Javascript parsing. And looking at the Basemark results, Krait is quite capable in that department.Reply

I don't know for sure, not a definitive answer here, just adding to the discussion.

Like you said, it's a reference design (Mobile Development Platform). They put as little time as possible into making this pretty.

When I was in college we had some old development platforms for some Motorola chips that were essentially a large circuit card with ports on all the sides for all the I/O and buttons to push for different operating modes like programming mode. It in no way looked like what an actual product would look like - because that wasn't its purpose.Reply

Granted, we're only given SunSpider and BrowserMark benchmarks for the Atom Z2460 reference platform, but they're both actually ahead of the numbers for the Krait MDP - 1331.5 versus 1532 on SunSpider and 116425 vs 110345 on BrowserMark. While I expected Atom to be competitive, I'd thought it likely for Krait to be slightly ahead on the single threaded benchmarks, so I'm somewhat surprised that it's not. (Note that I'm somewhat surprised that there was no mention of how Krait compares to Atom Z2460 in the article.)

As for power, that same article states that the Atom Z2460 SoC consumes ~750 mW at 1.6GHz - that's for the entire SoC, not just the CPU core. It'll be quite interesting to see how actual battery life compares between products once released.Reply

The difference is, one is Intel's numbers and the other is a 3rd party reviewer's on an actual device.

So yes, I agree. We'll have to see what actual phones using Atom will be like. Note that Sunspider isn't the end-all of "single-threaded performance" either. The JIT for Javascript on x86 is far more mature -- having been developed for a decade now -- than it is for ARM.Reply

Well, I tend to trust Intel's numbers when they're actual hard numbers rather than percentages or normalized figures - they can't exactly get away with making up figures.

And no question about the fact that SunSpider/Browsermark aren't indicative of all too much... but I wouldn't claim that Intel's advantages on those benchmarks are due to a superior JIT/software advantage. Remember the performance figures from that Oak Trail Tablet prototype running an early Android port from June of 2011? That was a prime example of the sort of software disadvantage that Intel had to overcome in order to get Android running well on x86. While a bit dated, here's an excellent example of the performance differences on x86 java implementations between OS (note that linux had a slightly newer version, but they were both using the latest available) - http://www.phoronix.com/scan.php?page=article&...Reply

No, but you'd be surprised how much a bit of pick-and-choose can help. Most comprehensive reviews are pretty rigorous with how many times they repeat a test, how much warm-up they give a device and whether or not they pick the median, average, etc.

One could easily pick the best number, which can vary quite a bit especially for a JIT benchmark.

I've also seen that comparison before. There was a rather thorough discussion of it and its relative lack of merits at RWT. I'd link, but it's being marked as spam :/Reply