Original Link: https://www.anandtech.com/show/8554/the-iphone-6-review
The iPhone 6 Review
by Joshua Ho, Brandon Chester, Chris Heinonen & Ryan Smith on September 30, 2014 8:01 AM EST- Posted in
- Apple
- Smartphones
- Mobile
- iPhone 6
With every launch of the iPhone, Apple seems to have everything to lose and not much to gain. Apple’s iPhone line accounts for the majority of profits in the smartphone space, and as the smartphone market marches towards maturity it seems inevitable that companies like Xiaomi will be able to deliver largely similar experiences at much lower prices. The same once happened with Apple in the days of the PC industry where Apple approached irrelevance. Yet generation after generation, Apple seems to be able to hold on to a majority of profit share, and they’ve managed to tenaciously hold on to their first-mover advantage.
This brings us to the iPhone 6. This is now the eighth generation of the iPhone, and the fifth generation of the iPhone’s industrial and material design. We should note right now that this review is specifically for the iPhone 6; for the iPhone 6 Plus, please see our iPhone 6 Plus companion review. At this point, it’s not really possible to revolutionize the smartphone, and on the surface, the iPhone 6 seems to be directly inspired by the iPod Touch. However, instead of the chamfered edge where the display meets the metal unibody we see a continuous curve from the sloping glass to the metal unibody that looks and feels great. While the M8 was one of the best phones for in-hand feel, the iPhone 6 goes a step further due to the reduced weight and rounded side. I've always felt like the HTC 8X had one of the most compelling shapes for a phone, and the incredibly thin feel of the iPhone 6 definitely reminds me of that.
Along the left side, we see the standard volume buttons and mute switch that continue to have the same solid feel and clean clicking action. As I discuss in the iPhone 6 Plus review, going by Consumer Reports' data it seems that there is a weak point near the bottom of the volume rocker, although it's far less likely to be an issue on the iPhone 6 due to its smaller size. Along the top, there isn’t a power button because it’s been moved to the right side of the phone so there’s nothing notable on the top.
On the right side, we see the previously mentioned power button and also the SIM tray, which is ejected by inserting a pin into the eject hole. Similarly to the volume buttons, the power button has a solid feel that gives a distinct click when triggered and continues to be quite unique when compared to phones other than recent iPhones.
The bottom has the Lightning connector, speaker, a microphone, and 3.5mm headset jack. The placement and design of all these elements are largely similar if not shared directly with the iPod Touch.
The back of the phone continues to share elements from the iPod Touch. The camera, microphone, and LED flash are almost identical in their appearance, even down to the camera hump’s design. The LED flash does look different to accommodate the second amber flash, but the shape is identical. The only real difference is that the antennas of the iPhone 6 are the metal pieces on the top and bottom, with the associated plastic lines instead of a plastic RF window.
The front of the phone is decidedly more similar to the iPhone 5s though, with the Touch ID home button. While the earpiece hasn’t moved, it seems that the front facing camera has been moved back to the left side of the earpiece, and the sensors for light and proximity are now above the earpiece. For the most part, there’s not much to comment on here but after using the iPhone 6 for an extended amount of time I’m definitely sure that the home button is relatively closer to the surface of the display glass than before. In addition, the home button has a dramatically improved feel, with short travel, clean actuation, and a reassuring click in most cases.
Overall, while I was undecided at the launch of the iPhone 6 I definitely think the look of the new iPhone has grown on me. The camera hump’s accent serves as an interesting design touch, and the feel of the design is definitely much more comfortable and ergonomic than before. I’m not really sure that the extra reduction in thickness was necessary, but it does make for a better first impression. In the launch article I was a bit surprised that Apple chose to have a camera hump but given the fact that the iPod Touch has the same design it seems that there is precedent for such a move. I personally feel that the design wouldn’t be worse by increasing thickness to eliminate the hump and improve battery life as a result.
Apple has also introduced a new silicone case, which brings a lower price point than the leather cases. Surprisingly, this is a rather high quality case, and as far as I can tell it doesn’t carry any of the issues that silicone cases traditionally have. There’s a nice lip to make sure that the display glass doesn’t touch a surface if the phone is put face down, and the material doesn’t seem to stretch or attract pocket lint the way most silicone cases do.
There’s definitely a lot more to talk about though, and to get a sense of the major differences I’ve put together our usual spec table below.
Apple iPhone 5s | Apple iPhone 6 | Apple iPhone 6 Plus | |
SoC | Apple A7 | Apple A8 | Apple A8 |
Display | 4-inch 1136 x 640 LCD | 4.7-inch 1334 x 750 LCD | 5.5-inch 1920 x 1080 LCD |
WiFi | 2.4/5GHz 802.11a/b/g/n, BT 4.0 | 2.4/5GHz 802.11a/b/g/n/ac, single stream, BT 4.0, NFC | |
Storage | 16GB/32GB/64GB | 16GB/64GB/128GB | 16GB/64GB/128GB |
I/O | Lightning connector, 3.5mm headset | ||
Size / Mass | 123.8 x 58.6 x 7.6 mm, 112 grams | 138.1 x 67 x 6.9 mm, 129 grams | 158.1 x 77.8 x 7.1 mm, 172 grams |
Camera |
8MP iSight with 1.5µm pixels Rear Facing + True Tone Flash 1.2MP f/2.4 Front Facing |
8MP iSight with 1.5µm pixels Rear Facing + True Tone Flash 1.2MP f/2.2 Front Facing |
8MP iSight with 1.5µm pixels Rear Facing + True Tone Flash + OIS 1.2MP f/2.2 Front Facing |
Price | $99 (16GB), $149 (32GB) on 2 year contract | $199 (16GB), $299 (64GB), $399 (128GB) on 2 year contract | $299 (16GB), $399 (64GB), $499 (128GB) on 2 year contract |
As you can see, this is a major release even at a high level. While the design might take some inspiration from the iPod Touch, the hardware is a completely different beast. There’s a new SoC, the A8; the iPhone 6 also includes a bigger and better display, newer WiFi module, bigger battery, and a better camera. Of course, there’s a lot more to the story of the iPhone 6 than a spec sheet. The first major difference that we’ll talk about is the SoC.
A8: Apple’s First 20nm SoC
As has been customary for every iPhone launch since the company began publicly naming their SoCs, Apple has once again rolled out a new SoC for their latest line of phones. With the launch of the iPhone 6 series Apple is now up to their eight generation SoC, the appropriately named A8.
After a period of rapid change with the A6 and A7 SoCs – which introduced Apple’s first custom CPU design (Swift) and the first ARMv8 AArch64 design (Cyclone) respectively – A8 is a more structured and straightforward evolution of Apple’s SoC designs. Which is not to say that Apple hasn’t been busy tweaking their designs to extract ever-improved performance and power efficiency, as we’ll see, but our examination of A8 has not uncovered the same kind of radical changes that defined A6 and A7.
The heart and soul of A8 is as always the CPU and GPU. We’ll be taking a look at each of these individually in a moment, but from a high level both of these are evolutions of their predecessors found in A7. Apple’s GPU of choice remains Imagination’s PowerVR, having upgraded from the Series6 based G6430 to Imagination’s newer GX6450 design. Meanwhile Apple continues to develop their own CPUs and A8 packs their latest design, which is an enhanced version of the Cyclone core first introduced in A7.
Stepping away from the GPU and CPU for the moment, the biggest change about A8 is that it’s smaller. As discovered by Chipworks, A8 is being fabricated on TSMC’s new 20nm process, making the iPhone 6 among the first smartphones to be shipped with a 20nm SoC.
This move to 20nm is not unexpected, but nonetheless it is considerable for a couple of reasons. The first is that this means Apple has moved production over to TSMC’s 20nm HKMG Planar process, making this the first time an Apple SoC has been manufactured anywhere but a Samsung fab. There are numerous possible reasons for this – and not every reason needs to be technical – but from a process development standpoint it’s important to note that over the last few generations TSMC has been the leader among contract foundries, being the first to get new processes up and running for volume production.
Apple A8 vs A7 SoCs | ||||
Apple A8 (2014) | Apple A7 (2013) | |||
Manufacturing Process | TSMC 20nm HKMG | Samsung 28nm HKMG | ||
Die Size | 89mm2 | 102mm2 | ||
Transistor Count | ~2B | "Over 1B" | ||
CPU | 2 x Apple Enhanced Cyclone ARMv8 64-bit cores |
2 x Apple Cyclone ARMv8 64-bit cores |
||
GPU | IMG PowerVR GX6450 | IMG PowerVR G6430 |
This move is also quite considerable because it means for the first time Apple is manufacturing their SoCs on a bleeding edge manufacturing process. Prior to this Apple has been slow to utilize new manufacturing processes, only finally utilizing a 28nm process in late 2013 for A7 over a year after 28nm first became available. The fact that we are seeing a 20nm SoC from Apple at a time when almost everyone else is still on 28nm indicates just how much the market has shifted over the last few years, and how Apple’s SoC development is now synchronized with the very edge of semiconductor fabrication technology.
Finally, the switch to 20nm is interesting because after the last couple of generations being so-called “half node” jumps – 45nm to 40nm to 32nm to 28nm – the jump from 28nm to 20nm is a full node jump (note that Apple didn't ever use 40nm, however). This means we are seeing a larger increase in transistor density than in the previous generations, and ideally a larger decrease in power consumption as well.
In practice TSMC’s 20nm process is going to be a mixed bag; it can offer 30% higher speeds, 1.9x the density, or 25% less power consumption than their 28nm process, but not all three at once. In particular power consumption and speeds will be directly opposed, so any use of higher clock speeds will eat into power consumption improvements. This of course gets murkier once we’re comparing TSMC to Samsung, but the principle of clock speed/power tradeoffs remains the same regardless.
Not accounting for minor differences between TSMC and Samsung, in an ideal case Apple is looking at 51% area scaling (the same design on 20nm can be no smaller than 51% of the die area at 28nm). In reality, nothing ever scales perfectly so the density gains will depend on the kind of I/C being laid down (logic, SRAM, etc.). For the complete chip a 60-70% scaling factor is going to be a better approximation, which for Apple means they’ve picked up a lot room to spend on new functionality and reducing their overall die size.
Apple SoC Evolution | |||||
CPU Perf | GPU Perf | Die Size | Transistors | Process | |
A5 | ~13x | ~20x | 122m2 | <1B | 45nm |
A6 | ~26x | ~34x | 97mm2 | <1B | 32nm |
A7 | 40x | 56x | 102mm2 | >1B | 28nm |
A8 | 50x | 84x | 89mm2 | ~2B | 20nm |
Meanwhile once again this year Apple opened up on die size and transistor counts. A8 weighs in at around 2 billion transistors, as opposed to the “over 1 billion” transistors found on A7. We also have the die size for A8 – 89mm2 – which is some 13% smaller than A7’s 102mm2 die. This makes it clear that Apple has chosen to split their transistor density improvements between adding features/performance and reducing their size, rather than going all-in on either direction.
In the case of using a bleeding edge node this is generally a good call, as Apple and TSMC will need to deal with the fact that chip yields at 20nm will not be as good as they are on the highly mature 28nm process. With lower chip yields, a smaller die will offset some of those yield losses by reducing the number of manufacturing flaws any given die touches, improving the overall yield.
Moving on, looking at A8 we can see that Apple’s memory subsystem design has not significantly changed from A7. Once again Apple has placed an SRAM cache on the chip to service both the CPU and the GPU. Based on an examination of the die and of latency numbers, this L3 SRAM cache remains unchanged from A7 at 4MB. Meanwhile we also find a series of SDRAM interfaces which drive the A8’s package-on-package (POP) based main memory. Based on teardowns from iFixit, Apple is using 1GB of LPDDR3-1600, the same speed grade of LPDDR3 and capacity that they used for the iPhone 5s. iFixit has found both Hynix and Elpida memory in their phones, so Apple is once again using multiple sources for their RAM.
When we start poking at memory bandwidth we find that memory bandwidths are consistently higher than on A7, but only ever so slightly. This points to Apple having worked out further optimizations to make better use of the memory bandwidth they have available, since as we’ve previously determined they’re still using LPDDR3-1600 speeds.
Geekbench 3 Memory Bandwidth Comparison (1 thread) | ||||||
Stream Copy | Stream Scale | Stream Add | Stream Triad | |||
Apple A8 1.4GHz | 9.08 GB/s | 5.37 GB/s | 5.76 GB/s | 5.78 GB/s | ||
Apple A7 1.3GHz | 8.34 GB/s | 5.21 GB/s | 5.67 GB/s | 5.69 GB/s | ||
A8 Advantage | 9% | 3% | 2% | 2% |
The Stream Copy score ends up being the biggest gain at 9%. Otherwise the rest of the benchmarks only show 2-3% memory bandwidth increases.
More interesting is memory latency, which shows some unexpected improvements once we get out of the L1 and L2 caches. At both the 1MB – 4MB region of the SRAM and 6MB+ region of main memory, memory latency is consistently lower on A8 versus A7. In both cases we’re looking at latencies about 20ns faster than A7. This identical 20ns gain tells us that that Apple is still doing main memory lookups after the L3 lookup fails, and this in turn means the 20ns gain we’re seeing is due to L3 cache optimizations. We have a couple of ideas for how Apple could have improved L3 latency by nearly 20% like this, but at this time with Apple staying quiet on their architecture like usual, it’s not apparent which of these ideas are the correct ones.
Turning our eyes back to A8 one final time, we find that while a lot of die space is occupied by the CPU, GPU, and SRAM (as we’d expect), there is also quite a bit of space occupied by other blocks Apple has integrated into their design. Without already knowing what you’re looking for these blocks are difficult to identify, but even without being able to do this we have a reasonable idea of what blocks Apple has integrated. Among these we’ll find audio controllers, USB controllers, video encoders/decoders, flash memory controllers, the camera ISP, and of course all kinds of interconnect.
All of these blocks are fixed function hardware (or at best, limited flexibility DSPs), which are equally important to not only the A8’s functionality but power efficiency. By assigning tasks to dedicated hardware Apple does spend some die space on that hardware, but in return these blocks are more efficient than doing those tasks entirely in software. Hence Apple (and SoC designers in general) have a strong incentive to offload as much work as possible to keep power consumption in check. This move towards more fixed function hardware is part of a general “wheel of reincarnation” cycle that has been a constant in processor design over the years, which sees a continuous shift between fixed function and programmable hardware. SoCs, for the most part, are still going towards fixed function hardware, and this should continue for a while yet.
In any case, while we can’t identify individual blocks on A8 we do know that Apple has added a few features to A8 that are present in some form or another among these blocks. New to A8 is some mix of H.265 (HEVC) hardware, which would be necessary to enable the FaceTime over H.265 functionality that is being introduced on the iPhone 6. Apple’s “desktop class scaler” that is used for handling non-native resolution applications and for down-sampling the internal rendering resolution of the iPhone 6 Plus would also be present here.
A8’s CPU: What Comes After Cyclone?
Despite the importance of the CPU in Apple’s SoC designs, it continues to be surprising just how relatively little we know about their architectures even years after the fact. Even though the CPU was so important that Apple saw the need to create their own custom design, and then did two architectures in just the span of two years, they are not fond of talking about just what it is they have done with their architectures. This, unfortunately, is especially the case at the beginning of an SoC’s lifecycle, and for A8 it isn’t going to be any different.
Overall, from what we can tell the CPU in the A8 is not a significant departure from the CPU in A7, but that is not a bad thing. With Cyclone Apple hit on a very solid design: use a wide, high-IPC design with great latency in order to reach high performance levels at low clock speeds. By keeping the CPU wide and the clock speed low, Apple was able to hit their performance goals without having to push the envelope on power consumption, as lower clock speeds help keep CPU power use in check. It’s all very Intel Core-like, all things considered. Furthermore given the fact that Cyclone was a forward-looking design with ARMv8 AArch64 capabilities and already strong performance, Apple does not face the same pressure to overhaul their CPU architecture like other current ARMv7 CPU designers do.
As a result, from the information we have been able to dig up and the tests we have performed, the A8 CPU is not radically different from Cyclone. To be sure there are some differences that make it clear that this is not just a Cyclone running at slightly higher clock speeds, but we have not seen the same kind of immense overhaul that defined Swift and Cyclone.
Unfortunately Apple has tightened up on information leaks and unintentional publications more than ever with A8, so the amount of information coming out of Apple about this new core is very limited. In fact this time around we don’t even know the name of the CPU. For the time being we are calling it "Enhanced Cyclone" – it’s descriptive of the architecture – but we’re fairly certain that it does have a formal name within Apple to set it apart from Cyclone, a name we hope to discover sooner than later.
In any case one of the things we do know about Enhanced Cyclone is that unlike Apple’s GPU of choice for A8, Apple has seen a significant reduction in the die size of the CPU coming from the 28nm A7 to the 20nm A8. Chipworks’ estimates put the die size of Cyclone at 17.1mm2 versus 12.2mm2 for Enhanced Cyclone. On a relative basis this means that Enhanced Cyclone is 71% the size of Cyclone, which even after accounting for less-than-perfect area scaling still means that Enhanced Cyclone is a relatively bigger CPU composed of more transistors than Cyclone was. It is not dramatically bigger, but it’s bigger to such a degree that it’s clear that Apple has made further improvements over Cyclone.
The question of the moment is what Apple has put their additional transistors and die space to work on. Some of that is no doubt the memory interface, which as we’ve seen earlier L3 cache access times are nearly 20ns faster in our benchmarks. But if we dig deeper things start becoming very interesting.
Apple Custom CPU Core Comparison | ||||||
Apple A7 | Apple A8 | |||||
CPU Codename | Cyclone | "Enhanced Cyclone" | ||||
ARM ISA | ARMv8-A (32/64-bit) | ARMv8-A (32/64-bit) | ||||
Issue Width | 6 micro-ops | 6 micro-ops | ||||
Reorder Buffer Size | 192 micro-ops | 192 micro-ops? | ||||
Branch Mispredict Penalty | 16 cycles (14 - 19) | 16 (14 - 19)? | ||||
Integer ALUs | 4 | 4 | ||||
Load/Store Units | 2 | 2 | ||||
Addition (FP) Latency | 5 cycles | 4 cycles | ||||
Multiplication (INT) Latency | 4 cycles | 3 cycles | ||||
Branch Units | 2 | 2 | ||||
Indirect Branch Units | 1 | 1 | ||||
FP/NEON ALUs | 3 | 3 | ||||
L1 Cache | 64KB I$ + 64KB D$ | 64KB I$ + 64KB D$ | ||||
L2 Cache | 1MB | 1MB | ||||
L3 Cache | 4MB | 4MB |
First and foremost, in much of our testing Enhanced Cyclone performs very similarly to Cyclone. Accounting for the fact that A8 is clocked at 1.4GHz versus 1.3GHz for A7, in many low-level benchmarks the two perform as if they are the same processor. Based on this data it looks like the fundamentals of Cyclone have not been changed for Enhanced Cyclone. Enhanced Cyclone is still a very wide six micro-op architecture, and branch misprediction penalties are similar so that it’s likely we’re looking at the same pipeline length.
However from our low-level tests two specific features stand out: integer multiplication and floating point addition. When it comes to integer multiplication Cyclone had a single multiplication unit and it took four cycles to execute. However against Enhanced Cyclone those operations are now measuring in at three cycles to execute. But more surprising is the total Integer multiplication throughput rate; integer multiplication performance has now more than doubled. While this doesn’t give us enough data to completely draw out Enhanced Cyclone’s integer pathways, all of the data points to Enhanced Cyclone doubling up on its integer multiplication units, meaning Apple’s latest architecture now has two such units.
Meanwhile floating point addition shows similar benefits, though not as great as integer multiplication. Throughput is such that there appears to still be three FP ALUs, but like integer multiplication the instruction latency has been reduced. Apple has managed to shave off a cycle on FP addition, so it now completes in four cycles instead of five. Both of these improvements indicate that Enhanced Cyclone is not identical to Cyclone – the additional INT MUL unit in particular – making them very similar but still subtly different CPU architectures.
Apple iPhone Performance Estimates: Over The Years
Outside of these low-level operations, most other aspects of Enhanced Cyclone seem unchanged. L1 cache remains at 64KB I$ + 64KB D$ per CPU core, where it was most recently doubled for Cyclone. For L2 cache Chipworks believes that there may be separate L2 caches for each CPU core, and while L2 cache bandwidth is looking a little better on Enhanced Cyclone than on Cyclone, it’s not a “smoking gun” that would prove the presence of separate L2 caches. And of course, the L3 cache stands at 4MB, with the aforementioned improvements in latency that we’ve seen.
To borrow an Intel analogy once more, the layout and performance of Enhanced Cyclone relative to Cyclone is quite similar to Intel’s more recent ticks, where smaller feature improvements take place alongside a die shrink. In this case Apple has their die shrink to 20nm; meanwhile they have made some small tweaks to the architecture to improve performance across several scenarios. At the same time Apple has made a moderate bump in clock speed from 1.3GHz to 1.4GHz, but it’s nothing extreme. Ultimately while two CPU architectures does not constitute a pattern, if Apple were to implement tick-tock then this is roughly what it would look like.
Moving on, after completing our low-level tests we also wanted to spend some time comparing Enhanced Cyclone with its predecessor on some high level tests. The low-level tests can tell us if individual operations have been improved while high level tests can tell us something about what the performance impact will be in realistic workloads.
For our first high level benchmark we turn to SPECint2000. Developed by the Standard Performance Evaluation Corporation, SPECint2000 is the integer component of their larger SPEC CPU2000 benchmark. Designed around the turn of the century, officially SPEC CPU2000 has been retired for PC processors, but with mobile processors roughly a decade behind their PC counterparts in performance, SPEC CPU2000 is currently a very good fit for the capabilities of Cyclone and Enhanced Cyclone.
SPECint2000 is composed of 12 benchmarks which are then used to compute a final peak score. Though in our case we’re more interested in the individual results.
SPECint2000 - Estimated Scores | ||||||
A8 | A7 | % Advantage | ||||
164.gzip |
842
|
757
|
11%
|
|||
175.vpr |
1228
|
1046
|
17%
|
|||
176.gcc |
1810
|
1466
|
23%
|
|||
181.mcf |
1420
|
915
|
55%
|
|||
186.crafty |
2021
|
1687
|
19%
|
|||
197.parser |
1129
|
947
|
19%
|
|||
252.eon |
1933
|
1641
|
17%
|
|||
253.perlbmk |
1666
|
1349
|
23%
|
|||
254.gap |
1821
|
1459
|
24%
|
|||
255.vortex |
1716
|
1431
|
19%
|
|||
256.bzip2 |
1234
|
1034
|
19%
|
|||
300.twolf |
1633
|
1473
|
10%
|
Keeping in mind that A8 is clocked 100MHz (~7.7%) higher than A7, all of the SPECint2000 benchmarks show performance gains above and beyond the clock speed increase, indicating that every benchmark has benefited in some way. Of these benchmarks MCF, GCC, PerlBmk and GAP in particular show the greatest gains, at anywhere between 20% and 55%. Roughly speaking anything that is potentially branch-heavy sees some of the smallest gains while anything that plays into the multiplication changes benefits more.
MCF, a combinatorial optimization benchmark, ends up being the outlier here by far. Given that these are all integer benchmarks, it may very well be that MCF benefits from the integer multiplication improvements the most, as its performance comes very close to tracking the 2X increase in multiplication throughput. This also bodes well for any other kind of work that is similarly bounded by integer multiplication performance, though such workloads are not particularly common in the real world of smartphone use.
Our other set of comparison benchmarks comes from Geekbench 3. Unlike SPECint2000, Geekbench 3 is a mix of integer and floating point workloads, so it will give us a second set of eyes on the integer results along with a take on floating point improvements.
Geekbench 3 - Integer Performance | ||||||
A8 | A7 | % Advantage | ||||
AES ST |
992.2 MB/s
|
846.8 MB/s
|
17%
|
|||
AES MT |
1.93 GB/s
|
1.64 GB/s
|
17%
|
|||
Twofish ST |
58.8 MB/s
|
55.6 MB/s
|
5%
|
|||
Twofish MT |
116.8 MB/s
|
110.0 MB/s
|
6%
|
|||
SHA1 ST |
495.1 MB/s
|
474.8 MB/s
|
4%
|
|||
SHA1 MT |
975.8 MB/s
|
937 MB/s
|
4%
|
|||
SHA2 ST |
109.9 MB/s
|
102.2 MB/s
|
7%
|
|||
SHA2 MT |
219.4 MB/
|
204.4 MB/s
|
7%
|
|||
BZip2Comp ST |
5.24 MB/s
|
4.53 MB/s
|
15%
|
|||
BZip2Comp MT |
10.3 MB/s
|
8.82 MB/s
|
16%
|
|||
Bzip2Decomp ST |
8.4 MB/
|
7.6 MB/s
|
10%
|
|||
Bzip2Decomp MT |
16.5 MB/s
|
15 MB/s
|
10%
|
|||
JPG Comp ST |
19 MP/s
|
16.8 MPs
|
13%
|
|||
JPG Comp MT |
37.6 MP/s
|
33.3 MP/s
|
12%
|
|||
JPG Decomp ST |
45.9 MP/s
|
39 MP/s
|
17%
|
|||
JPG Decomp MT |
89.3 MP/s
|
77.1 MP/s
|
15%
|
|||
PNG Comp ST |
1.26 MP/s
|
1.14 MP/s
|
10%
|
|||
PNG Comp MT |
2.51 MP/s
|
2.26 MP/s
|
11%
|
|||
PNG Decomp ST |
17.4 MP/s
|
15.1 MP/s
|
15%
|
|||
PNG Decomp MT |
34.3 MPs
|
29.6 MP/s
|
15%
|
|||
Sobel ST |
71.7 MP/s
|
58.1 MP/s
|
23%
|
|||
Sobel MT |
137.1 MP/s
|
112.4 MP/s
|
21%
|
|||
Lua ST |
1.64 MB/s
|
1.34 MB/s
|
22%
|
|||
Lua MT |
3.22 MB/s
|
2.64 MB/s
|
21%
|
|||
Dijkstra ST |
5.57 Mpairs/s
|
4.04 Mpairs/s
|
37%
|
|||
Dijkstra MT |
9.43 Mpairs/s
|
7.26 Mpairs/s
|
29%
|
Geekbench’s integer results are overall a bit more muted than SPECint2000’s, but there are still some definite high points and low points among these benchmarks. Crypto performance is among the lesser gains, while Sobel and Dijkstra are among the largest at 21% and 37% respectively. Interestingly in the case of Dijkstra, this does make up for the earlier performance loss Cyclone saw on this benchmark in the move to 64-bit.
Geekbench 3 - Floating Point Performance | ||||||
A8 | A7 | % Advantage | ||||
BlackScholes ST |
7.85 Mnodes/s
|
5.89 Mnodes/s
|
33%
|
|||
BlackScholes MT |
15.5 Mnodes/s
|
11.8 Mnodes/s
|
31%
|
|||
Mandelbrot ST |
1.18 GFLOPS
|
929.4 MFLOPS
|
26%
|
|||
Mandelbrot MT |
2.34 GFLOPS
|
1.85 GFLOPS
|
26%
|
|||
Sharpen Filter ST |
981.7 MFLOPS
|
854 MFLOPS
|
14%
|
|||
Sharpen Filter MT |
1.94 MFLOPS
|
1.7 GFLOPS
|
14%
|
|||
Blur Filter ST |
1.41 GFLOPS
|
1.26 GFLOPS
|
11%
|
|||
Blur Filter MT |
2.78 GFLOPS
|
2.49 GFLOPS
|
11%
|
|||
SGEMM ST |
3.83 GFLOPS
|
3.44 GFLOPS
|
11%
|
|||
SGEMM MT |
7.48 GFLOPS
|
6.4 GFLOPS
|
16%
|
|||
DGEMM ST |
1.87 GFLOPS
|
1.68 GFLOPS
|
11%
|
|||
DGEMM MT |
3.61 GFLOPS
|
3.14 GFLOPS
|
14%
|
|||
SFFT ST |
1.77 GFLOPS
|
1.59 GFLOPS
|
11%
|
|||
SFFT MT |
3.47 GFLOPS
|
3.18 GFLOPS
|
9%
|
|||
DFFT ST |
1.68 GFLOPS
|
1.47 GFLOPS
|
14%
|
|||
DFFT MT |
3.29 GFLOPS
|
2.93 GFLOPS
|
12%
|
|||
N-Body ST |
735.8 Kpairs/s
|
587.8 Kpairs/s
|
25%
|
|||
N-Body MT |
1.46 Mpairs/s
|
1.17 Mpairs/s
|
24%
|
|||
Ray Trace ST |
2.76 MP/s
|
2.23 MP/s
|
23%
|
|||
Ray Trace MT |
5.45 MP/s
|
4.49 MP/s
|
21%
|
While the low-level floating point tests we ran earlier didn’t show as significant a change in the floating point performance of the architecture as it did the integer, our high level benchmarks show that floating point tests are actually faring rather well. Which goes to show that not everything can be captured in low level testing, especially less tangible aspects such as instruction windows. More importantly though this shows that Enhanced Cyclone’s performance gains aren’t just limited to integer workloads but cover floating point as well.
Overall, even without a radical change in architecture, thanks to a combination of clock speed increases, architectural optimizations, and memory latency improvements, Enhanced Cyclone as present in the A8 SoC is looking like a solid step up in performance from Cyclone and the A7. Over the next year Apple is going to face the first real competition in the ARMv8 64-bit space from Cortex-A57 and other high performance designs, and while it’s far too early to guess how those will compare, at the very least we can say that Apple will be going in with a strong hand. More excitingly, most of these performance improvements build upon Apple’s already strong single-threaded IPC, which means that in those stubborn workloads that don’t benefit from multi-core scaling Apple is looking very good.
A8’s GPU: Imagination Technologies’ PowerVR GX6450
Last but not least on our tour of the A8 SoC is Apple’s GPU of choice, Imagination’s PowerVR GX6450.
When Apple first announced the A8 SoC as part of their iPhone keynote, they told us to expect a nearly 50% increase in graphics performance. Based on that information and on the fact that that Apple was moving to a denser 20nm process, we initially believed that Apple would be upgrading from A7’s 4-core PowerVR design to a 6-core design, especially in light of the higher resolution displays present on the iPhone 6 and iPhone 6 Plus.
Instead our analysis with Chipworks found that only four GPU cores were present on A8, which ruled out the idea of a 6-core design but did narrow down the options considerably. Based on that information and more importantly Apple’s Metal Programming Guide, we have been able to narrow down our options to a single GPU, the PowerVR GX6450.
The GX6450 is the immediate successor to the G6430 first used in the A7 and is based on Imagination’s PowerVR Series6XT architecture. Imagination first announced PowerVR Series6XT to the public at CES 2014, and now just a short eight months later we are seeing the first Series6XT hardware reach retail.
We have already covered the PowerVR Series6/Series6XT architecture in some detail earlier this year so we won’t go through all of it again, but we would encourage anyone who is interested to take a look at our architectural analysis for additional information. Otherwise we will be spending the bulk of our time looking at how GX6450 differs from G6430 and why Apple would choose this specific GPU.
From a technical perspective Series6XT is a direct evolution over the previous Series6, and GX6450 is a direct evolution over G6430 as well. Given a 4-core configuration there are only a limited number of scenarios where GX6450 outright has more hardware than G6430 (e.g. additional ALUs), and instead Series6XT is focused on adding features and improving performance over Series6 through various tweaks and optimizations to the architecture. Series6 at this point is actually over two years old – it was first introduced to the public at CES 2012 – so a lot has happened in the mobile GPU landscape over the past couple of years.
The closest thing to a marquee feature on Series6XT is support for Adaptive Scalable Texture Compression (ASTC), a next-generation texture compression technology that is slowly making its way into GPUs from a number of manufacturers. Designed by the consortium responsible for OpenGL ES, Khronos, ASTC is designed to offer better texture compression (with finer grained quality options) than existing texture compression formats while also being a universal format supported by all GPUs. In Apple’s case they have always been using PowerVR GPUs – and hence all products support PVRTC and more recently PVRTC2 – however ASTC being exposed allows them to take advantage of the quality improvements while also making game development and porting from other platforms easier.
Less visible to users but certainly important to Apple, Series6XT also includes new power management capabilities to reduce power consumption under idle and light workloads. Through finer grained power gating technology that Imagination dubs “PowerGearing G6XT”, GX6450 can now have its shading clusters (USCs) powered down individually, allowing only as many of them as are necessary to be fired up. As Apple continues to min-max their designs, being able to idle at a lower power state can be used to improve battery life and/or increase how often and how long the A8’s GPU uses higher power states, improving overall efficiency.
Apple iPhone GPU Performance Estimate: Over The Years
And, perhaps most importantly overall, Series6XT comprises a series of under-the-hood optimizations to improve overall performance. When it comes to the internals of PowerVR architectures we only have limited details from Imagination on how they operate, so in some areas we know quite a bit about what Imagination has been up to and in other areas their architectures are still something akin to a black box. At any rate Imagination’s goal for Series6XT was to improve performance by up to 50% – this seems to be where Apple’s 50% performance improvement claim comes from – though as we’ll see the performance gains on real world applications are not going to be quite as potent.
What we do know about Series6XT is that Imagination has made some changes to the structure of the USCs themselves. Series6XT still uses a 16-wide SIMD design, but in each pipeline they have added another set of medium/half-precision (FP16) ALUs specifically to improve FP16 performance. Now instead of 2x3 (6) FP16 ALUs, Series6XT bumps that up to 4x2 (8) FP16 ALUs. This is the only outright increase in shader hardware when you compare Series6 to Series6XT, and on paper it improves FP16 performance by 33% at equivalent clock speeds.
The focus on FP16 is interesting, though for iOS it may be misplaced. These half-precision floating point operations are an excellent way to conserve bandwidth and power by not firing up more expensive FP32 ALUs, but the tradeoff is that the numbers they work with aren’t nearly as precise, hence their use has to be carefully planned. In practice what you will find is that while FP16 operations do see some use, they are by no means the predominant type of floating point GPU operation used, so the FP16 increase is a 33% increase only in the cases where performance is being constrained by the GPU’s FP16 performance.
FP32 performance meanwhile remains unchanged. Each USC pipeline contains two such ALUs, for up to four FP32 FLOPS per clock, or to use our typical metric, 128 MADs (Multiply-Adds) per clock.
The rest of Series6XT’s optimizations take place at the front and back ends, where geometry processing and pixel fill take place respectively. Imagination has not told us exactly what they have done here, but both these areas have been targeted to improve sustained polygon rates and pixel fillrate performance. These more generic optimizations stand to be more applicable to general performance, though by how much we cannot say.
One final optimization we want to point out for Series6XT is that Imagination has made some additional under-the-hood changes to improve GPU compute performance. We have not talked about GPU compute on iOS devices thus far, as until now Apple has not exposed any APIs suitable for it (e.g. OpenCL is not available on iOS). With iOS8 Apple is releasing their Metal API, which is robust enough to be used for both graphics and now compute. How developers put this capability to use remains to be seen, but GX6450 should perform even better than G6430.
Mobile SoC GPU Comparison | ||||||||||
PowerVR SGX 543MP2 | PowerVR SGX 543MP3 | PowerVR SGX 543MP4 | PowerVR SGX 554MP4 | PowerVR G6430 | PowerVR GX6450 | |||||
Used In | iPad 2/iPhone 4S | iPhone 5 | iPad 3 | iPad 4 | iPad Air/iPhone 5s | iPhone 6/iPhone 6Plus | ||||
SIMD Name | USSE2 | USSE2 | USSE2 | USSE2 | USC | USC | ||||
# of SIMDs | 8 | 12 | 16 | 32 | 4 | 4 | ||||
MADs per SIMD | 4 | 4 | 4 | 4 | 32 | 32 | ||||
Total MADs | 32 | 48 | 64 | 128 | 128 | 128 | ||||
GFLOPS @ 300MHz | 19.2 GFLOPS | 28.8 GFLOPS | 38.4 GFLOPS | 76.8 GFLOPS | 76.8 GFLOPS | 76.8 GFLOPS | ||||
Pixels/Clock | N/A | N/A | N/A | N/A | 8 | 8 | ||||
Texels/Clock | N/A | N/A | N/A | N/A | 8 | 8 |
The one wildcard when talking about performance here is going to be clock speeds. Apple doesn’t expose these and they aren’t easy to test for (yet), though in the long term Metal offers some interesting possibilities for nailing that down, or at least getting a better idea of relative clock speeds.
In any case, we’ll take a look at our GPU benchmarks in depth in a bit, but overall GPU performance compared to A7 and its G6430 is consistently better, but the exact performance gain will depend on the test at hand. Some tests will come very close to reaching 50% while others will be just 15-20%. The dependent factor generally seems to be whether the test is ALU-bound or not; because the USC has not changed significantly from G6430 to GX6450 outside of those additional FP16 ALUs, tests that hit the FP32 ALUs in particular show less of an improvement. Otherwise more balanced tests (or at least tests more defined by pixel fillrate performance) can show greater gains. In general we should be looking at a 30-35% performance improvement.
Why Four Cores?
One thing that admittedly surprised us in the revelation that A8 was using a 4-core PowerVR design was that we figured a 6-core design would be a shoe-in for A8, especially since Apple was on the receiving end of the density improvements from TSMC’s 20nm process. But upon further reflection an additional two cores is likely more than Apple needed nor wanted.
The biggest factor here is that coming from G6430 in the A7, performance has seen a solid improvement despite sticking to only four GPU cores. Due to the combination of performance improvements from the Series6XT architecture and any clock speed increases from Apple, A8 gets quite a bit more GPU performance to play with. The increased resolution of the iPhone 6 screen in turn requires more performance if Apple wants to keep native resolution performance from significantly regressing, which GX6450 is capable of delivering on. Never mind the fact that G6430 also drove the iPad Air and its much larger 2048x1536 pixel display.
PowerVR Series6/6XT "Rogue" | ||||||||||||
GPU | # of Clusters | # of FP32 Ops per Cluster | Total FP32 Ops | Optimization | ||||||||
G6200 | 2 | 64 | 128 | Area | ||||||||
G6230 | 2 | 64 | 128 | Performance | ||||||||
GX6240 | 2 | 64 | 128 | Area | ||||||||
GX6250 | 2 | 64 | 128 | Performance | ||||||||
G6400 | 4 | 64 | 256 | Area | ||||||||
G6430 | 4 | 64 | 256 | Performance | ||||||||
GX6450 | 4 | 64 | 256 | Performance | ||||||||
G6630 | 6 | 64 | 384 | Performance | ||||||||
GX6650 | 6 | 64 | 384 | Performance |
These performance improvements in Series6XT have a cost as well, and that cost is suitably reflected in the estimated die sizes for each GPU. The G6430 was 22.1mm2 on the 28nm A7, while the GX6450 is 19.1mm2 on A8. Though GX6450 is smaller overall, it’s nowhere near the roughly 11.1mm2 a pure and perfect die shrink of G6430 would occupy. Limited area scaling aside, GX6450’s additional functionality and additional performance requires more transistors, and at the end of the day Apple doesn’t see a significantly smaller GPU because of this. In other words, the upgrade from G6430 to GX6450 has delivered much of the performance (and consumed much of the die space) we initially expected to be allocated to a 6-core GPU.
Overall the choice of GX6450 seems to be one of picking the GPU best for a phone, which is an area the G6430 proved effective with A7. As a step below Imagination’s 6-core PowerVR designs, GX6450 delivers a better balance between performance and power than a larger GPU would, which in turn is clearly a benefit to Apple. On the other hand this means A8 is not going to have the GPU performance to compete with the fastest SoCs specifically designed for tablets, though what this could mean for the obligatory iPad update remains to be seen.
CPU Performance
Now that we have a good idea of what the A8 SoC looks like, we can talk about performance. While we covered this in the preliminary article, it’s worth going over again. For those that are unfamiliar with our test suite the CPU-based tests are mostly browser-based benchmarks. Once again, although I’m not quite happy with the state of benchmarking things we’re getting close to a more platform-agnostic solution.
For the most part, the A8 SoC performs admirably despite the relatively low (1.38 GHz) frequency and half the cores when compared to competing SoCs. It seems that this is mostly building upon the lead that A7's Cyclone CPUs began. It remains to be seen if other SoC manufacturers will catch up in their CPU architecture at one point or another (NVIDIA's Project Denver in particular is interesting), but for now Apple seems to be quite far in the lead in CPU performance.
GPU Performance
While we don't quite have real games to benchmark against, we do have benchmarks that are reasonably good approximations of games, which heavily stress the GPU. For the most part, this means that we can see the performance of the A8's PowerVR GX6450 GPU but there are some aspects that are CPU-bound, which we'll discuss after the results.
Edit: Before I get into the results, I must caution that Basemark X will have inaccurate on-screen results as the benchmark was made using XCode 5.x in order to keep scores comparable between versions 1.1 and 1.1.1. This doesn't affect the overall score, which is solely calculated based upon off-screen performance.
For the most part, we see that the GX6450 is at about the same level as Qualcomm's Adreno 420, which seems to track closely to expectations given that the A7's GPU was around the same performance as the Adreno 330. The 3DMark test does have an interesting result, but it seems that this is because 3DMark's physics test has a strong amount of data dependency that restricts the level of out of order execution that can be done. NVIDIA's Tegra K1 is the current leader in graphics performance, but of course it's also in a tablet instead of a smartphone so it's not a direct competitor.
NAND Performance
As we move towards the goal of seamless performance in everyday tasks, one significant factor is IO performance. While there's definitely a minimum level of performance that allows for generally acceptable smoothness, there's value in having higher storage performance (e.g. prevent bottlenecking in situations such as updating apps in the background). In order to test this, we use Androbench with some custom settings on Android and a custom utility developed by Eric Patno for iOS, who has been quite helpful with furthering our efforts to test storage performance.
As this is the first time that we've looked into NAND performance on iOS devices, it's definitely worth scrutinizing the data a bit more closely than in most cases. There are a few notable cases here, which are the class-leading speeds for sequential reads and writes on the iPhone 6, but also the rather middling random read and write speeds for the iPhone 6 and 5s. The oddest result is definitely the iPhone 5, which is Ryan's personal unit and while the random read speeds are on the low side, random write speeds are easily record-setting.
In practice, with tablets and smartphones being less multitasking heavy than PCs/laptops, the sequential scores are probably slightly more relevant to the overall user experience. The iPhone 6 results show a significant increase in performance over the iPhone 5s in all of the tests, which is always good to see.
Battery Life
Battery life is undoubtedly one of the most important aspects of any smartphone. However, battery life is an enormous subject, and while it may seem simple on the surface there’s a great deal of underlying complexity. In order to try and cover the full breadth of use cases, we start with our baseline test, which is now the web browsing battery life test. In order to try and control for extraneous variables and get a good relative comparison, we standardize all displays to 200 nits on a full white display.
Our first test is in WiFi web browsing. As we can see, the iPhone 6 puts up a surprising showing for a phone with such a small battery. If anything, it seems that Apple leaned towards the conservative side in their advertised numbers as we managed to get higher than expected battery life. It may seem strange that the iPhone 6 achieves such a strong showing despite the small battery, but this is because the test is designed to avoid penalizing a phone for having a faster SoC or data connection.
In LTE web browsing, we see the same story. The iPhone 6 is about equal to or better than the competition, which is in line with what we would expect given the cellular architecture. In the case of the iPhone 6 and most other flagship smartphones this year, components such as Qualcomm’s QFE1100 envelope tracker, WTR1625 transceiver, and MDM9x25 modem have managed to make LTE power consumption approximately equal to WiFi power consumption. With the deployment of category 6 LTE and next generation RF components we could see LTE battery life exceed WiFi battery life.
While the web browsing test gives us a good picture of battery life in display-bound tasks, intensive use tends to be more SoC-bound. In order to see how phones compare in SoC-bound workloads, we turn to GFXBench, which has an infinite looping test. This test also provides a good idea of nominal performance. Unfortunately, for now we cannot report an accurate Basemark OS II battery life score as the test will stop when low battery notifications pop up on the screen. We are currently investigating methods to bypass this issue and report a final score in the near future.
In the GFXBench test, at first it seems that the iPhone 6 is one of the worst for battery life under sustained load. However, once we look at the performance degradation over time it makes a lot more sense. This seems to be the type of workload that Apple referenced in their presentations, because this is the first phone I’ve seen that successfully does a full rundown without actually throttling. Of course, this does come with high skin temperatures. The phone definitely gets hot, but not uncomfortable. Using a FLIR camera, I saw peak temperatures of around 43 degrees Celcius, so it definitely doesn't exceed 50C in most conditions.
Normally, I would expect a 4.7” class smartphone to need a battery around the size of the HTC One (M7) or Motorola Moto X (2013) to keep pace with phones like the One (M8) and Galaxy S5, but Apple has pulled it off with a battery that is much smaller. There are two key factors that we can point to in this case. The first is the display, which can avoid pushing the LED backlight towards the higher current region that is much less efficient. This is because the amount of light-blocking circuitry is reduced and the active area of the display can be higher. The second aspect is the SoC, which is on a lower power 20nm process node. While TSMC’s 20nm process doesn’t have FinFET, improved silicon straining and high K metal gate make it possible to drive down active power and leakage when compared to 28nm processes. It’s also likely that the A8’s architecture is more efficient than other SoCs we’ve seen this year. However, it's important to note that without a capacitance and voltage table or something similarly concrete we can't really prove this statement.
Charge Time
While battery life determines the time spent away from a charger, the time spent attached to a charger is just as important. Even if most people charge their phones at night, there are plenty of cases where people don't have at least five hours to spend charging their phone. For example, forgetting to plug the phone into a charger before going to sleep or charging a phone between connecting flights are all times when charge time becomes crucial. In order to properly test for charge time, charge time is measured as the time from when the phone is connected to the charger to the time when the A/C adapter reaches its lowest power state with the phone still connected.
As you can see, the iPhone 6 performs reasonably well, and ends up in the same range as the iPhone 5s. The iPhone 6 Plus ends up on the high side because it ships with the same power adapter as the iPhone 6, which can provide a maximum of one amp at five volts.
Fortunately, based on the USB device information for the phones, both the iPhone 6 and 6 Plus support charging with power adapters like the iPad charging block that can provide up to 2.1 amps at five volts. Using one of these chargers will dramatically reduce charge time on the new iPhones, and it's a very worthwhile investment (assuming you don't already have an iPad) for the iPhone 6 Plus in particular.
Display
As the primary mode of interaction with the phone, the display is one of the most important areas of evaluation. Of course, the methods of evaluation can be hotly debated. There is a great deal of subjectivity in this area in terms of what someone prefers. However, for the sake of color calibration our tests follow world-wide standards instead of personal preference one way or another. This means that we use the sRGB gamut and 2.2 gamma, which most content is adapted to. While AdobeRGB and other gamuts exist, these are for limited use cases and only applicable to operating systems that are aware of multiple gamuts and can dynamically switch between them depending upon the metadata of the content. In order to accurately test for how well a display conforms to these standards, we use SpectraCal’s CalMAN 5 along with a spectrophotometer for accurate color readings.
For those that are unfamiliar with the display of the iPhone 6 and Apple’s key marketing points on this new model, the improvements are mostly centered on higher resolution, contrast, and better viewing angles. In terms of higher resolution the iPhone 6 moves from the 1136x640 pixels of the iPhone 5/5s generation to 1334x750 pixels. However, this doesn’t improve the pixel density, which remains at 326 pixels per inch.
In practice, I definitely continue to notice the difference in resolution when using the iPhone 6 as opposed to the higher pixel density iPhone 6 Plus and the various Android smartphones with 450+ PPI displays. I definitely don’t find the resolution to be a problem though, as these issues only become significant to me below 300 PPI. I do think that around 450 to 500 PPI is the right place to be when balancing pixel density and power, but Apple’s choice should pay off in the form of better power consumption especially because LED backlights rapidly lose efficiency near the highest current region.
The other issue at hand is that of viewing angles. While Apple is one of the first to really talk about dual domain pixels, this technique is rather commonly used to improve viewing angles. The result is that a pair of pixels will appear to be a chevron, and overall the pixels appear to be squiggly in nature. While this doesn’t really change the readability of the display at extreme angles, colors like white no longer have noticeable red/yellow/blue shifts depending upon the angle that the display is shifted at.
This is definitely noticeable in everyday use, as the iPhone 5s could only avoid color shifting at certain angles instead of every angle. As I predicted in the launch article though, the one caveat seems to be that black has a noticeable shift towards purple in certain angles. There's also a noticeable hatching on close examination, but this doesn't affect image quality. This is definitely better than what I see on AMOLED though, as while AMOLED has much better brightness stability the color shifting is far more obvious and significant.
Now that we’ve covered the other two, we can talk about contrast. For this test, we measure brightness of 100% white and black at maximum display brightness, and look at the ratio. While we’re looking into getting patterns that can’t be defeated by dynamic contrast/backlight this should give an idea of best case contrast. In this case, peak brightness is on the high side at 560 nits, with relatively low black brightness at about a third of a nit. The result is one of the best contrast ratios I’ve ever seen. While the HTC One (M7) has a 1743:1 contrast ratio in our tests, some testing I’ve done indicates that the true contrast ratio is realistically around that of the One (M8). I’m not quite sure how this was done, but Apple stated that a new deposition process was used for the liquid crystals. This, along with changes to the liquid crystals themselves, could be responsible for the improved contrast.
The next part to talk about is grayscale, which is an area where Apple seemed to prefer bluer color balances. I don’t really have much to pick at here, because the level of calibration here is incredible. While there is a noticeable trend of overshooting red at the low end and undershooting red at the high end, this is nitpicking at best. At any rate, this is essentially perfect.
Our next test is the saturation sweep, which tests each primary and secondary color for accuracy in hue and luminance. While it’s true that humans can be relatively insensitive to differences in saturation, it is all too common to see OEMs artificially compress saturations to have vivid colors and be able to claim that they have an accurate display because it matches the sRGB gamut. In this test, the iPhone 6 sets a new record. I really don’t have any objections here because a dE2000 value of 1.19 is a deviation that is almost impossible to notice.
The final test is the Gretag MacBeth ColorChecker, which tests various hues and is usually one of the hardest tests to perform well in. In this regard, the iPhone 6 once again sets a new record for accuracy. This display is effectively calibrated to sRGB, and one would be hard pressed to find a significant deviation when compared to a reference monitor.
Overall, it’s hard to find any criticism for this display. I would normally be incredibly suspicious to see these numbers on a smartphone, but the fact that there’s a hot pixel in the center of the display suggests to me that this was not a cherry-picked unit. The fact that I find this level of calibration to be suspicious speaks volumes about how good this display is. While contrast isn't AMOLED levels of black, there are no purple smearing effects, noticeable uneven luminance near black, or any other idiosyncrasies.
Camera
In order to really understand the camera of the iPhone 6, we have to first talk about the components that make up the camera system. While we don’t know the exact model number of either the iPhone 5s or iPhone 6 sensors, we do know that both the front and rear cameras are made by Sony. For the most part, it seems that the optical system is largely unchanged from the iPhone 5s to iPhone 6. The focal length and aperture are identical, and both have five plastic lenses. On the sensor side there are some obvious differences such as the addition of phase detection pixels. However, it’s otherwise difficult to say if anything else has changed in this area. There’s also a new ISP on the SoC, which serves to enable features like 240FPS slow motion video.
Based on what we know about the camera, the one highlight feature seems to be PDAF. While we’ve seen it before in phones like the Galaxy S5, we’ve never really talked about how it works. In short, microlenses on the sensor refract incoming light onto the AF detector in pairs, as seen in the photo below. Once this is done, the image produced by each AF sensor is compared for similarities. By finding these similarities, the ISP can know whether the lens is focused at a point short, long, or on the intended subject and command lens movement to focus on the intended subject. In case 1 in the photo, we see a situation where the camera is focused short, so the lens must move in order to properly focus on the subject, which is case 2. Case 3 and 4 show increasingly extreme cases of focusing too far to focus on the subject.
Source: Wikipedia
The real question is how it works. While we don't have an ideal test for auto focus and capture latency, we can at least get an idea for best case latency by looking at latency for both cases when viewing a well lit ISO chart, which has extremely high contrast and strong lighting so PDAF should be able to operate.
As you can see, it seems that capture latency is mostly unchanged when comparing the two phones but focus latency is dramatically improved in the best case, which is around 200 milliseconds. While the Galaxy S5 does have PDAF, in my experience it was hard to tell if it was any faster than a mostly contrast-based solution like the One M8. With the iPhone 6 the use of PDAF is immediately obvious because in well lit conditions the camera always snaps to focus without ever waiting for the ISP to detect an out of focus condition and run an AF scan. Oddly enough, in all of the manual camera applications that I've tried none of them seem to be able to use continuous auto focus in the preview, which suggests that this isn't exposed in the camera API.
On the UI side, the new camera application isn't a significant departure from what we're used to in iOS but there is one odd UI inconsistency present in the new UI, as in the slow motion video mode tapping the fps option will toggle between 120 and 240 fps but the same isn't true of 1080p60 video, which has to be toggled through the settings application instead of within the camera application.
Otherwise, I'm generally happy with the camera, especially with the new exposure biasing mode which does away with the need to try and get a specific exposure by locking exposure and reframing to get the right photo. While this certainly isn't a new feature the ease of use makes for a better implementation than most. Generally, exposure biasing is hidden in the settings menu so it's a setting that is only selected once and never again. However, Apple's solution will always default to 0 EV and allow for biasing by swiping up to increase exposure and down to reduce it, which means that this solution is fast and easy to do when taking a photo.
Overall, I don't have significant complaints with the camera UI or the general shooting experience. While I'm still looking for an ideal manual camera application I find Apple's mostly all auto solution to be more than sufficient. Of course, the shooting experience alone isn't enough to evaluate a camera so we'll look at image quality next.
Still Image Performance
While I'm still not quite happy with the state of our camera testing procedures, our current tests can generally give a good relative comparison, so the data we're looking at can still be used to draw some conclusions about the camera being tested. One of the first tests that we'll look at is the ISO chart, which uses increasingly tight line spacing to determine what the maximum resolution of the camera is.
In this test, the iPhone 6 does reasonably well, showing low aliasing until around the 16 or 17 mark, which seems to be about the same as the iPhone 5s. In general, this is one area where the iPhone falls short of the competition, which generally tends towards 1.1 micron pixels and sensor sizes larger than a third of an inch. However, it's definitely a great more detail than what we see on the four megapixel sensor of the One (M7) or One (M8). Given the sensor size constraints that Apple seems to be working with this is a respectable showing.
The next scene we'll look at is a daytime landscape shot. For the most part the iPhone 6 does admirably, as noise is well suppressed without noticeable oil painting effects that arise from when noise suppression is too strong and blurs out detail. Dynamic range is also generally quite good as shadowed areas have noticeable detail in this scene. In comparison to the iPhone 5s, while it's relatively hard to see any real differences in detail the noise in areas like the sky and in shadows are noticeably reduced without an obvious decrease in detail.
Following along the lines of the landscape shot, I also set up a lightbox scene with a few objects of varying contrasting textures, text, and feature size to get a good idea of what the limitations of the camera are. In this test scene, we actually see some level of improvement in detail when comparing the iPhone 5s to the iPhone 6. This is most obvious when looking closely at the texture of the metal bell. When compared to the Galaxy S5 LTE-A the iPhone 6 does fall behind a bit due to lower resolution and a mildly wider field of view.
For the next scene, I used the light box and standardized dim lighting in order to provide an example of camera performance between extremely bright and dark scenes. Here, it's relatively difficult to see a difference between the various phones, although with some cameras we're already starting to see a significant amount of detail blurred away in areas like the bell which has a great deal of low contrast detail. There's not too much difference here when comparing the iPhone 6 and 5s, although the 6 does have noticeably lower contrast in these situations.
At the extremes of low light photos, we definitely see a notable improvement in the iPhone 6, which can be attributed to the lower ISO. However, for better or worse we don't see a significant difference in exposure which suggests that this sensor likely has improved sensitivity despite identical pixel size. While we have no way of knowing the exact sensor, it's logical to conclude that the iPhone 6 is using a CMOS sensor process similar to the IMX240 in the GS5 LTE-A at a larger pixel pitch for better sensitivity. What's really incredible about this test photo is that the iPhone 6 manages to deliver an output close to what we see in the iPhone 6 Plus at four times the ISO/sensor gain.
The next two test cases are less about the camera itself and more about how well the OEM has integrated software and hardware. The first test we'll go over is the LED flash test in the lightbox scene that was previously used. While LED flash is generally a rather poor solution for low light photos, it's still important to test as there are some situations where it's absolutely necessary. In this case, Apple has done a great job of selecting an appropriate brightness level to evenly illuminate the scene and provided enough light to keep noise to a minimum, but for some reason there's a pink/red tint to the entire scene. This is one area where the iPhone 5s seems to provide more even color rendering as there is no such tint.
In the HDR test, there's a noticeable improvement in detail and dynamic range from the iPhone 5s to the iPhone 6. Key areas of note include the Media Link HD box, which has noticeably clearer text and there's also significantly more detail on the bell. Judging by the general improvements to detail in closer shots, it may be that these effects are either too subtle to see in landscapes or simply smudged away by noise reduction. There's relatively little to criticize here, as Apple seems to be effectively merging multiple exposures without obvious halos or similar effects that make HDR almost impossible to use in most circumstances.
Overall, the iPhone 6's camera represents a solid improvement over the previous generation, with less noise, more detail in some circumstances, better HDR, and improved low light performance. While it isn't a huge leap ahead, it's definitely more than one might expect. The improvements are subtle though, as there are no fundamental changes to the optics or sensor.
Video Quality
At a high level, video recording seems to be mostly similar. Both the iPhone 5s and iPhone 6 continue to rely on EIS for video stabilization, both seem to use somewhat similar optics and sensors, and both can only shoot 1080p video. However, the details are really where we see improvements in the iPhone 6. For starters, the iPhone 6 now has 1080p60 video support, which is definitely helpful for improving spatial resolution and general performance. There's also 720p240 slow motion video, which is an addition to the 720p120 video that we saw in the iPhone 5s.
Video Encode Settings (Approx.) | ||||||
iPhone 5s | iPhone 6 | |||||
1080p30 | 17 Mbps High Profile H.264 | 17 Mbps High Profile H.264 | ||||
1080p60 | - | 27 Mbps High Profile H.264 | ||||
720p120 | 27 Mbps High Profile H.264 | 31 Mbps High Profile H.264 | ||||
720p240 | - | 42 Mbps High Profile H.264 |
As you can see, there's really not a massive difference in encoding bitrate, at least for the standard video record settings. However, even casual examination shows just how big a difference there is when comparing video from the iPhone 5s to video from the iPhone 6.
While the YouTube compression is likely to make it hard to see whether the iPhone 6 really has better video quality, when viewed at full resolution with Quicktime it seems that there is some level of improvement, but this could be due to the smaller field of view that is used when compared to the iPhone 5s. This tighter FOV also seems to be part of the reason why the stabilization is more effective than before. At various points in the video, it's quite obvious that the iPhone 6 is also benefiting greatly from PDAF as we see seamless transitions throughout the video and consistently better focus while the iPhone 5s is locked from the start and would require multiple taps to refocus the video.
1080p60 brings significant improvements to temporal quality, as capturing fast motion is noticeably more fluid when compared to 1080p30. Video stabilization is also retained, which makes 1080p60 an easy choice when capturing fast-moving objects.
As with the iPhone 5s, the original video on NAND is saved to play back at either 120 or 240 fps, but on the phone and when uploaded to social media the slow motion versions play back certain parts at 30 fps. As far as I can tell, there's relatively little difference in the image quality between the two modes, but this advantage is unlikely to hold when in lower light situations as the frame rate inherently caps the exposure time.
Audio Quality
The iPhone 6 is the first non-Android phone to be put onto the Audio Precision APx582 for audio testing. The exact same test tones are used as with Android devices, but they are played back through iTunes at maximum volume. We use the same four static loads as we did with the HTC M8 and Samsung Galaxy S5 for the results you see in the table below.
15 Ohm | 33 Ohm | 150 Ohm | 330 Ohm | |
Dynamic Range | 84.155 dB | 92.281 dB | 92.223 dB | 92.160 dB |
THD+N | 5.873% | 0.0054% | 0.0032% | 0.0032% |
Crosstalk (L) | -49.608 dB | -56.239 dB | -71.721 dB | -77.966 dB |
Crosstalk (R) | -49.831 dB | -56.459 dB | -72.191 dB | -77.983 dB |
Output Power | 44.04 mW | 26.39 mW | 6.614 mW | 3.072 mW |
Output Voltage | 812.7 mVrms | 933 mVrms | 997 mVrms | 1,007 mVrms |
Relative Level (20Hz - 20kHz) | ±0.088 dB | ±0.088 dB | ±0.089 dB | ±0.088 dB |
HTC M8 | iPhone 6 | Galaxy S5 | |
Dynamic Range | 92.074 dB | 92.281 dB | 91.921 dB |
THD+N | 0.0152% | 0.0054% | 0.0505% |
Crosstalk (L) | -64.780 dB | -56.239 dB | -44.767 dB |
Crosstalk (R) | -64.329 dB | -56.459 dB | -44.804 dB |
Output Power | 47.63 mW | 26.39 mW | 10.63 mW |
Output Voltage | 1.254 Vrms | 933 mVrms | 592.4 mVrms |
Relative Level (20Hz - 20kHz) | ±0.664 dB | ±0.088 dB | ±0.081 dB |
Design
The iPhone 6 comes with Apple’s newly released iOS 8. For a full rundown of everything Apple is bringing to the table with iOS 8 you can read our review of the operating system itself. iOS 8 also includes changes that are specific to the iPhones 6 and 6 Plus. Much like when Apple moved from the 3.5” 3:2 display in previous iPhones to the 4” 16:9 display on the iPhone 5, these changes are to add support for the new display on the iPhone 6. The home screen now displays an additional row of icons, meaning that it fits even more than an iPad. In addition, all of Apple’s default applications have been updated to take advantage of the larger, higher resolution screen.
Weather. iPhone 6 on the left, iPhone 5s on the right.
In the case of applications like Calculator, the interface simply has larger assets with the same layout as the 4” iPhones. Other applications like Settings and Notes display the elements of the interface at the same size as previous iPhones which allows more to be fit on the screen. Unlike the iPhone 5 which shared the same width as previous iPhones, the increase in space applies along both display axes on the iPhone 6 Plus. This is well demonstrated by the new Weather application which now fits more of the hourly forecast horizontally and more of the weekly forecast vertically.
The keyboard has also been updated to take advantage of the larger display when in landscape mode. The right side of the keyboard has been given dedicated keys for moving the cursor left and right in a text box, as well as a period button. The left side has an undo key and a comma. When the emoji keyboard is enabled it also receives a dedicated button next to the toggle between letters and numbers/special characters.
Another application with landscape specific improvements is Safari. While the iPhone 6 does not get the new split landscape views in applications that the 6 Plus has, it does get the horizontal tab view in Safari and the sliding bookmark menu on the new tab page. What's interesting is that this Safari interface is nearly identical to that of the iPad version, which is similar to Safari on OS X Yosemite. The one difference is that tabs in the tab view that are from the same website do not stack on top of each other. Apple really seems to want a unified interface and experience for Safari across all of their platforms, and the general design of the interface has translated well to the various different display sizes on iOS and OS X devices.
The iPhone 6 includes a feature called Reachability for users who find the increased display size difficult to use with one hand. Apple is late to the party with their larger displays, and we’ve seen attempts in the past by other manufacturers to make large devices easier to use. Shrinking the interface and displaying it in a bottom corner was a feature Samsung introduced with the Galaxy Note 3. It wasn’t a very elegant solution, but it worked. Apple’s Reachability feature uses a similar idea but implements it in a more elegant fashion. Double-tapping the capacitive ring around the home button shifts the display downward so the top of applications can be easily pressed. Once an action is performed the interface shifts back into position.
The last new feature specific to the new iPhones is Display Zoom. Display Zoom increases the size of what is displayed so that the interface displays the same amount of information that is shown on the iPhone 5, with an internal rendering resolution of 1136x640. This means that all icons, buttons, etc. are displayed in a much larger size than the default view setting. Because everything is being scaled up to the 1334x750 panel, the interface suffers from the slight blurring that you also see in third party apps that have not been updated to support the new iPhones. This feature is likely aimed at users with aging eyes who would like a bigger display to display bigger controls rather than to display more content, and who aren't concerned about having the sharpest text.
A notable feature that is missing is Apple's new Apple Pay service that works with the NFC hardware in the iPhone 6 and 6 Plus. Although Apple Pay is a feature of the new iPhones and of iOS 8, the service will not be rolling out until October. Other iOS 8 features like SMS Relay and iCloud Photo Library were also absent from the initial iOS 8 release and are scheduled to launch in October. It's likely that the fact that the iOS 8 release date is determined by the yearly release of new iPhones forced some features to be pushed back to a later update.
UX
While the design of iOS 8 itself is generally well-implemented, the user experience ends up a bit more mixed, and the result comes from the confluence of hardware and software. In the case of the iPhone 6, these issues effectively boil down to RAM and odd layouts that come from the upscaling needed for the 1334x750 display. In the case of upscaling artifacts, this is a temporary issue at best but it's glaringly obvious when an application is upscaled in certain cases.
For example, Trillian is an IM application that hasn't been updated in over a year. While it was already lacking in functionality with iOS 7 as it lacked support for the background refresh API, on the iPhone 6 in iOS 8 there are significant issues with consistent spacing and there's also no support for third party keyboards. Once again, it's important to understand that this isn't the result of poor work on Apple's part, but it does show the limits of what can be done with the upscaling system and emphasizes the need for developers to keep their applications updated.
The other issue has the potential to be far more serious. While iOS' software architecture is more RAM efficient due to manual garbage collection and the use of precompiled binaries, it's quite easy for me to push the phone past the breaking point in Safari. For example, six tabs of common websites for mobile devices cannot consistently be held in memory. If I continuously go through all six tabs, at least one will need to reload. In my first attempt at running this test, Safari crashed as I tried to go through all tabs constantly to keep them in memory. I didn't notice this behavior in the new Moto X, which can do the same test without issue. Outside of memory intensive use cases though, the iPhone 6 does respectably and I usually don't notice the lack of RAM. I have to emphasize that this should be a generally unlikely problem, and that the same behavior can be replicated on the iPhone 5s given the same workload. If you did not have issues with out of memory crashes before, there won't be any issues now.
Outside of these two flaws, there's really a lot to like. iOS continues to deliver a relatively well-polished experience that few seem to be able to match. Most of my issues from the iPhone 5s experience have been resolved. For example, it's now possible for me to upload photos to Dropbox selectively instead of turning camera upload on and deleting photos that I don't want to upload. The odd segregation of current notifications and missed notifications has been removed. Swiftkey has been added, although it's not quite the same as the Android version due to the different prediction insertion behavior and keyboard layout.
In addition, although it isn't necessarily the result of software, the larger display really helps with improving touch accuracy when compared to the iPhone 5s. While I haven't been able to try out Apple Pay since it will be launching in October, it also seems to be quite intriguing as the NFC solution is quite novel, though I'd like to see further use of NFC outside of payment and similar applications. TouchID continues to be a key differentiator, and the use of TouchID for Apple Pay authentication would definitely show the strength of Apple's hardware and software integration.
Cellular
As was previously announced, the iPhone 6 and 6 Plus both have support for carrier aggregation and VoLTE. For those that are unfamiliar with the two technologies, carrier aggregation is a method of combining multiple pieces of spectrum for simultaneous use, so it would be possible to piece together one band of 10 MHz and another band of 10 MHz spectrum to achieve the same rate that one would get with a single band of 20 MHz LTE. VoLTE is the next generation of voice service that is delivered over LTE, thus eliminating the need for complicated circuit-switched fallback mechanisms to WCDMA or GSM that are currently required. This is all enabled by the move to Qualcomm's MDM9x25 Gobi modem, which is built on 28HPm and therefore brings lower power when compared to the MDM9x15 generation fabricated on 28LP.
GNSS
As the iPhone 6 has Qualcomm's Gobi MDM9x25 modem inside, it goes without saying that it also has IZat Gen 8B. While it isn't possible to force GPS-only location and location is disabled when airplane mode is on, with WiFi turned off and no SIM inserted in the phone a location lock occurs in around 11 seconds.
Misc
While we normally do a WiFi performance test, for some reason it is no longer possible to get a good iperf port for the iPhone 6. It's likely that we're looking at a single spatial stream solution, and given the track record of Broadcom design wins for the WiFi/BT combo chip it's likely that this is a BCM4339 solution. Apple continues to integrate noise cancellation in the earpiece, and at least two microphones are integrated into the phone. Subjectively the single downward-firing speaker reaches acceptable levels of volume although I haven't been able to get the necessary equipment to test peak volume.
Final Words
Overall, the iPhone 6 is a significant step up from the iPhone 5s. One of the first areas where we see noteworthy changes is in the industrial design of the phone. Instead of the hard edges that we saw with the iPhone 5 design, the sides of the phone are now all curved in nature to give much better in-hand feel, and the result is surprisingly appealing as well due to how the glass curves down to meet the metal body. The iPhone 6 is also sitting right around the best balance of display size and one-handed usability, which helps with the in-hand feel aspect. I really have to make it a point to address size in the case of the iPhone 6. While this is definitely a matter of personal opinion and will vary from person to person, I find the size of the iPhone 6 to be refreshing after using phone after phone that pushed display size too far. While Reachability is definitely helpful, the size of the iPhone 6 is such that I really wouldn't miss such a feature on the iPhone 6 because it is an appropriate size. I never really had any issue handling a flagship from 2013 like the Nexus 5, Galaxy S4, G2, or One (M7), so this is a recent issue for me. Those that find those phones to be a good size will likely find the iPhone 6 to be similarly fit for their hands.
While I like the iPhone 6’s industrial design, increasing overall thickness to eliminate the camera hump could be an interesting variation as it would also bring a larger battery. Some users may also dislike the thick plastic lines, though I personally don’t notice this in day to day use.
The display itself is also a solid improvement, with incredible native contrast, high brightness, great viewing angles, and great calibration. I still feel like I’d want higher pixel density to make it the “perfect” display, but it’s clear that there are some very real limitations on resolution selection for iOS devices due to the point system used. Given that the resolution cannot be changed, the iPhone 6’s display is ultimately one of the best I’ve seen all year.
The SoC is also a significant upgrade, although not quite the jump that we saw from A6 to A7. For the most part, the architecture of the new CPU cores is relatively similar and we see a jump in GPU performance that puts the GX6450 on par with the Adreno 420. Apple continues to ship some of the best CPU and GPU choices on the market, and in our GFXBench rundown test it’s obvious that Apple has an extremely efficient system as skin temperatures remain in check while running at maximum performance for the duration of the GFXBench test. It’s clear that the NAND is also of high performance, although random I/O performance isn’t quite as amazing as sequential performance.
In battery life, once again Apple has managed to successfully maintain good battery life despite a relatively small battery capacity. The iPhone 6’s battery life is consistently near the top tier in this category. In the GFXBench rundown where the iPhone 6 falls short it makes up for it with incredible sustained performance.
Outside of the basic user experience, there are still even more improvements. The new camera seems to have better low light performance than before, along with significantly improved focus speed. The continuous auto focus enabled by phase detection autofocus is a killer feature for video when combined with the improved stabilization function. For a relatively small sensor size, Apple has managed to drive performance that rivals the relatively larger cameras of the competition. At the 1/3” sensor size, I’m not aware of a camera that is more balanced in its capabilities for daytime photography, low light photography, and anything in between.
In audio quality, Apple has delivered a solution on par with HTC’s audio solution, which places it among the best for this generation that we’ve tested. While there are some issues, there’s relatively little value to pushing audio quality any further unless high resolution audio becomes common.
Finally, the software experience continues to be great. Apple has taken advantage of the increased display size to increase information density out of the box, and generally improved the polish of iOS with iOS 8. We continue to see strong integration of TouchID into software, and with time I expect to see its value increase even more as Apple Pay and the use of TouchID for third party apps becomes widespread. There are only two significant issues that I noticed in my week with the iPhone 6, and one is because the application was originally intended for iOS 6. The only flaw that the iPhone 6 has is a lack of RAM, and this is only an issue if you also felt it was an issue on the iPhone 5s.
Overall, the iPhone 6 has been a surprise for me. While not all that much changed on the surface, this is the first phone that I’ve reviewed all year where I’ve found more to like the deeper I dug. The iPhone 6 is a great phone in its own right and needs no qualifications in that recommendation. While as a current Android user I’m still reluctant to use the iPhone 6 as my only phone, the iPhone 6 is good enough that I’m willing to consider doing so.