Qualcomm Snapdragon S4 (Krait) Performance Preview - 1.5 GHz MSM8960 MDP and Adreno 225 Benchmarks
by Brian Klug & Anand Lal Shimpi on February 21, 2012 3:01 AM EST- Posted in
- Smartphones
- Snapdragon
- Qualcomm
- Adreno
- Krait
- Mobile
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.
Facebook
Twitter
RSS
86 Comments
View All Comments
k1ng617 - Tuesday, February 21, 2012 - link
Honestly, I don't trust Linpack and believe it is probably one of the most outdated android benchmarks, that doesn't represent what a person will see with realworld user experience.Can you try out Antutu & CFBench and post the scores please?
juicytuna - Tuesday, February 21, 2012 - link
Indeed. Linpack is a test of software as much as hardware, who knows what kind of optimizations they could have done to the VM to get these headline grabbing scores.GPU is distincly meh for a 2012 soc, and single threaded performance doesn't seem that impressive to me. Sunspider and Browsermark seem to be on a par with what you'd expect to see from an A9@1.5ghz.
And how much of that 'faster feel' can be attributed to NAND performance?
metafor - Wednesday, February 22, 2012 - link
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.arm.svenska - Tuesday, February 21, 2012 - link
Why is the phone so long? I get that it is a reference design. But, could someone tell why it is like that?douglaswilliams - Tuesday, February 21, 2012 - link
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.
peevee - Tuesday, February 21, 2012 - link
Out-of-order Krait core at 1.5GHz consumes only 750mW. An Atom core at the same frequency consumes as much as 10x of that! While being in-order, no faster, if not slower! What a fail for Intel!Khato - Tuesday, February 21, 2012 - link
You might consider reading Anandtech's article covering the Intel Atom Z2460 launch in January - http://www.anandtech.com/show/5365/intels-medfield...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.
metafor - Tuesday, February 21, 2012 - link
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.
Khato - Tuesday, February 21, 2012 - link
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&...
metafor - Tuesday, February 21, 2012 - link
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 :/