At this point it probably isn’t a secret that tablet sales have leveled off, and in some cases they have declined. Pretty much anywhere you care to look you’ll see evidence that the tablet market just isn’t as strong as it once was. It’s undeniable that touch-only tablets have utility, but it seems that the broader market has been rather lukewarm about tablets. I suspect at least part of the problem here is that the rise of the phablet has supplanted small tablets. Large tablets are nice to have, but almost feel like a luxury good when they’re about as portable as an ultrabook. While a compact laptop can’t easily be used while standing, or any number of other situations where a tablet is going to be better, a compact laptop can do pretty much anything a touch-only tablet can. A laptop is also going to be clearly superior for a significant number of cases, such as typing or precise pointing.

As a result, large touch-only tablets feel like they’ve been limited to home use as a computer away from the computer. Tablets are great when you’re on the couch or in bed, but once you get to this point there are some obvious questions as to whether it makes sense to drop $500+ USD on a tablet that seems to have relatively limited utility. The Surface lineup has been showing signs of growth, but in general the Surface is more of a mix between laptop and tablet rather than a tablet. I would argue that given the OS and overall design that the Surface and Surface Pro are really more laptop than tablet, even if at the hardware level the Surface Pro 4 and Surface 3 are basically tablets with kickstands and keyboard covers.

If you’re guessing that this means Apple has had some issues with growing sales of their iPad lineup, you’d be right. From my first experiences with the iPad 3, I was impressed with the improved user experience for things like web browsing and other smartphone tasks, but I never really felt like it made enough sense to get one for myself. The iPad Air 2 was once again impressive and I felt like I could recommend it to other people that wanted a tablet, but I personally struggled to come up with a reason why I would buy it.

This brings us to the iPad Pro. This is probably the first time Apple has seriously deviated from traditional iPad launches, putting together a tablet built for (limited) productivity and content creation rather than just simple content consumption, creating what's arguably the iPad answer to the Surface Pro. To accomplish this, Apple has increased the display size to something closer to that of a laptop, and we see the addition of a stylus and a keyboard cover for additional precision inputs. Of course, under the hood there have been a lot of changes as well, so the usual spec sheet can be found below to summarize those changes.

	Apple iPad Air 2	Apple iPad Pro
SoC	Apple A8X 3 x Apple Typhoon @ 1.5GHz	Apple A9X 2 x Apple Twister @ 2.2GHz
GPU	PowerVR 8 Cluster Series6XT (Apple GXA6850)	PowerVR 12 Cluster Series7XT
RAM	2GB LPDDR3	4GB LPDDR4
NAND	16/64/128GB	32/128GB
Display	9.7" 2048x1536 IPS LCD	12.9" 2732x2048 IPS LCD
Size and Mass	240 x 169.5 x 6.1mm 437g WiFi, 444g LTE	305.7 x 220.6 x 6.9 mm 713g WiFi, 723g LTE
Camera	8MP Rear-Facing, f/2.4, 1.1 micron, 1.2MP Front-Facing, f/2.2
Battery	27.3Wh	38.5Wh
Launch OS	iOS 8	iOS 9
Cellular Connectivity	MDM9x25 Category 4 LTE + GPS/GNSS in Cellular SKU
Other Connectivity	2x2 802.11a/b/g/n/ac + BT 4.2, Apple Lightning
SIM	Optional NanoSIM
Price	$499/599/699 16/64/128GB	$799/949/1079 32/128GB/128GB LTE

At a high level, the iPad Pro gains a larger display with a higher resolution, more memory, a new SoC, and a larger battery to compensate for the change in display size. In addition to these changes, the iPad Pro also brings noticeable changes to the speakers, with an increase to four speakers which allow the iPad Pro to compensate for device orientation when projecting stereo audio.

Design

The most immediate change that you can see in the iPad Pro is the sheer size. The 12.9” display of the iPad Pro basically makes it feel like you’re carrying a laptop around. I would argue that this doesn’t actually affect the portability of the iPad Pro, but this is mostly because the iPad Air 2 was something that I only carried in a backpack to begin with. People carrying their tablets in a small bag, purse, or even just in their hands will notice the difference, so the change in size might be more or less noticeable depending upon how you carry things around.

The increase in size does affect weight. After significant use, I honestly don’t think the mass is a significant issue. It does feel heavier than the iPad Air 2, but the mass distribution is such that there isn’t a ton of battery hanging out at the edges of the device where it’ll affect the moment of inertia. This does raise the question of whether Apple included enough battery for sufficient battery life, but that’s a question best left for the rest of the review.

In terms of design, the iPad Pro is rather unremarkable if you’ve ever seen an iPad Air before; it is for all intents and purposes a bigger iPad Air. On the front, the display dominates, with some bezels on the sides and top. The top has the front-facing camera, and the bottom has the home button with TouchID.

Looking at the sides of the tablet, the top edge has the power button and 3.5mm port, along with two of the four speakers. The right edge has the volume buttons, and the bottom edge has the Lightning port and the other two speakers. The left edge is mostly empty, but contains the Smart Connector for the Smart Keyboard and similar accessories.

The back of the tablet is mostly unremarkable as well. For the LTE model, an RF window is visible on the top of the device to allow LTE and other connectivity to function. For the WiFi variants, it looks like the bottom display bezel and the bottom two speakers are the RF windows, so there aren’t any visible areas that indicate where the WiFi antennas are.

Overall, the iPad Pro feels like an iPad, with nothing all that remarkable beyond its size which is carried well. I never really noticed the mass or size of the iPad Pro even if it is clearly larger and heavier than the iPad Air 2. I also didn’t notice any issues with the back cover flexing, but given enough pressure on the back cover pretty much any device this large will see some screen distortion or bending. The iPad Pro does technically regress in thickness compared to the iPad Air 2, but I never noticed the difference in practice, especially when the larger display is really what matters more.

SoC Analysis: Apple A9X

Diving into the heart of the iPad Pro, we have Apple’s latest generation tablet SoC, A9X. Like the other Apple X series SoCs before it, A9X is by and large an enhanced and physically larger version of Apple’s latest phone SoC, taking advantage of the greater space and heat dissipation afforded by a tablet to produce a more powerful SoC.

Apple's A9X (Image Courtesy iFixit)

That Apple has developed a new SoC to launch alongside the iPad Pro is in no way surprising, but just as how the iPad Pro has ramifications for the overall iPad lineup as Apple gets into the productivity tablet market, iPad Pro’s genesis is reflected in its component selection. Apple already needed a powerful SoC for the iPad Air 2 in order to keep performance up with the tablet’s high resolution of the screen, and iPad Pro in turn pushes Apple’s performance needs even harder. Not only is there an even higher resolution screen to drive – the 2732x2048 display has about 66% of the pixels of a 4K display – but now Apple needs to deliver suitable performance for content creation and meaningful multitasking. I don’t want to imply that the A9X was somehow specifically designed from scratch for the iPad Pro, as there are a number of more important engineering considerations, but I do want to highlight how the iPad Pro is not just another iPad, and that as Apple expands the capabilities of the iPad they need to expand the performance as well if they wish to extend their reputation for smooth UX performance.

Looking at the specifications of the A9X, it seems like Apple always throws us a curveball on the X series SoCs, and for their latest SoC this is no different. With A8X Apple delivered more RAM on a wider memory bus, a larger GPU, and surprisingly, three Typhoon CPU cores. To date it’s still not clear just why Apple went with three CPU cores on A8X – was it for multitasking, or as an alternative means to boost performance – and A9X’s configuration only serves to highlight this enigma.

Apple SoC Comparison
	A9X	A9	A8X	A6X
CPU	2x Twister	2x Twister	3x Typhoon	2x Swift
CPU Clockspeed	2.26GHz	1.85GHz	1.5GHz	1.3GHz
GPU	PVR 12 Cluster Series7XT	PVR 6 Cluster Series7 (PVR GT7600)	PVR 8 Cluster Series6XT (APL GXA6850)	PVR SGX554 MP4
RAM	4GB LPDDR4	2GB LPDDR4	2GB LPDDR3	1GB LPDDR2
Memory Bus Width	128-bit	64-bit	128-bit	128-bit
Memory Bandwidth	51.2GB/sec	25.6GB/sec	25.6GB/sec	17.1GB/sec
L2 Cache	3MB	3MB	2MB	1MB
L3 Cache	None	4MB	4MB	N/A
Manufacturing Process	TSMC 16nm FinFET	TSMC 16nm & Samsung 14nm	TSMC 20nm	Samsung 32nm

Instead of continuing with a triple-core CPU design for A9X, for their latest X series SoC Apple has dropped back down to just a pair of Twister CPU cores. The catch here – and why two cores is in many ways better than three – is that relative to A8X and A9, Apple has cranked up their CPU clockspeeds. Way, way up. Whereas the iPad Air 2 (A8X) shipped at 1.5GHz and the iPhone 6s (A9) at 1.85GHz, the A9X sees Apple push their clockspeed to 2.26GHz. Not counting the architectural changes, this is 22% higher clocked than the A9 and 51% higher than the A8X.

The fact that Apple dropped back down to 2 CPU cores is unexpected given that we don’t expect Apple to ever go backwards in such a fashion, and while we’ll never know the official reason for everything Apple does, in retrospect I’m starting to think that A8X was an anomaly and Apple didn’t really want a tri-core CPU in the first place. A8X came at a time where Apple was bound by TSMC’s 20nm process and couldn’t drive up their clockspeeds without vastly increasing power consumption, so a third core was a far more power effective option.

A9X Die Shot w/AT Annotations (Die Shot Courtesy Chipworks)

Overall this means that iPad Pro and A9X will set a very high bar for tablet CPU performance. As we’ve already seen in the iPhone 6s review, the Twister CPU core is very potent and in most cases faster than any other ARM CPU core by leaps and bounds. Cranking up the clockspeed a further 22% only serves to open up that gap even further, as Twister is now reaching clockspeeds similar to the likes of Cortex-A57 and A72, but with its much wider execution pipeline and greater IPC. This is also the reason that an Intel Core CPU comparison is so interesting, as Intel’s tablet-class Core processors in many ways are the target to beat on overall CPU performance, and we’ll be touching upon this subject in greater detail a bit later.

GPU: Imagination PowerVR 12 Cluster Series 7XT

Meanwhile on the GPU side, as expected Apple has further increased the number of clusters on their SoC to drive the higher resolution display of a tablet. Whereas A9 used a 6 cluster design (PVR GT7600), A9X doubles this, giving us a relatively massive 12 cluster design.

In Imagination’s PowerVR Series7XT roadmap, the company doesn’t have an official name for a 12 cluster configuration, as this falls between the 8 cluster GT7800 and 16 cluster GT7900. So for the moment I’m simply calling it a “PowerVR 12 cluster Series7XT design,” and with any luck Imagination will use a more fine-grained naming scheme for future generations of PowerVR graphics.

In any case, the use of a 12 cluster design is a bit surprising from an engineering standpoint since it means that Apple was willing to take the die space hit to implement additional GPU clusters, despite the impact this would have on chip yields and costs. If anything, with the larger thermal capacity and battery of the iPad Pro, I had expected Apple to use higher GPU clockspeeds (and eat the power cost) in order to save on chip costs. Instead what we’re seeing is a GPU that essentially offers twice the GPU power of A9’s GPU.

However to put all of this in context, keep in mind that iPad Pro’s display is 5.95Mpixels, versus the 2.07Mpixel screen on the iPhone 6s Plus. So although Apple has doubled the number of GPU clusters for A9X – and I suspect clocked it fairly similarly – that increased performance will be very quickly consumed by the iPad Pro’s high resolution screen. Consequently even a 12 cluster GPU design is something of a compromise; if Apple wanted to maintain the same level of GPU performance per pixel as in the iPhone 6s family, they would have needed an even more powerful GPU. Which just goes to show how demanding tablets can be.

Memory Subsystem: 128-bit LPDDR4-3200, No L3 Cache

Responsibility for feeding the beast that is A9X’s GPU falls to A9X’s 128-bit LPDDR4 memory controller configuration. With twice as many GPU clusters, Apple needs twice as much memory bandwidth to maintain the same bandwidth-to-core ratio, so like the past X-series tablet SoCs, A9X implements a 128-bit bus. For Apple this means they now have a sizable 51.2GB/sec of memory bandwidth to play with. For an SoC this is a huge amount of bandwidth, but at the same time it’s quickly going to be consumed by those 12 GPU clusters.

Geekbench 3 Memory Bandwidth Comparison (1 thread)
	Stream Copy	Stream Scale	Stream Add	Stream Triad
Apple A9X 2.26GHz	20.8 GB/s	15.0 GB/s	15.3 GB/s	15.1 GB/s
Apple A8X 1.5GHz	14.2 GB/s	7.44 GB/s	7.54 GB/s	7.49 GB/s
A9X Advantage	46.4%	101%	103%	102%

It’s also while looking at A9X’s memory subsystem however that we find our second and final curveball for A9X: the L3 cache. Or rather, the lack thereof. For multiple generations now Apple has used an L3 cache on both their phone and tablet SoCs to help feed both the CPU and GPU, as even a fast memory bus can’t keep up with a low latency local cache. Even as recent as A9, Apple included a 4MB victim cache. However for A9X there is no L3 cache; the only caches on the chip are the individual L1 and L2 caches for the CPU and GPU, along with some even smaller amounts for cache for various other functional blocks..

The big question right now is why Apple would do this. Our traditional wisdom here is that the L3 cache was put in place to service both the CPU and GPU, but especially the GPU. Graphics rendering is a memory bandwidth-intensive operation, and as Apple has consistently been well ahead of many of the other ARM SoC designers in GPU performance, they have been running headlong into the performance limitations imposed by narrow mobile memory interfaces. An L3 cache, in turn, would alleviate some of that memory pressure and keep both CPU and GPU performance up.

One explanation may be that Apple deemed the L3 cache no longer necessary with the A9X’s 128-bit LPDDR4 memory bus; that 51.2GB/sec of bandwidth meant that they no longer needed the cache to avoid GPU stalls. However while the use of LPDDR4 may be a factor, Apple’s ratio of bandwidth-to-GPU cores of roughly 4.26GB/sec-to-1 core is identical to A9’s, which does have an L3 cache. With A9X being a larger A9 in so many ways, this alone isn’t the whole story.

What’s especially curious is that the L3 cache on the A9 wasn’t costing Apple much in the way of space. Chipworks puts the size of A9’s 4MB L3 cache block at a puny ~4.5 mm2, which is just 3% the size of A9X. So although there is a cost to adding L3 cache, unless there are issues we can’t see even with a die shot (e.g. routing), Apple didn’t save much by getting rid of the L3 cache.

Our own Andrei Frumusanu suspects that it may be a power matter, and that Apple was using the L3 cache to save on power-expensive memory operations on the A9. With A9X however, it’s a tablet SoC that doesn’t face the same power restrictions, and as a result doesn’t need a power-saving cache. This would be coupled with the fact that with double the GPU cores, there would be a lot more pressure on just a 4MB cache versus the pressure created by A9, which in turn may drive the need for a larger cache and ultimately an even larger die size.

As it stands there’s no one obvious reason, and it’s likely that all 3 factors – die size, LPDDR4, and power needs – all played a part here, with only those within the halls of One Infinite Loop knowing for sure. However I will add that since Apple has removed the L3 cache, the GPU L2 cache must be sizable. Imagination’s tile based deferred rendering technology needs an on-chip cache to hold tiles in to work on, and while they don’t need an entire frame’s worth of cache (which on iPad Pro would be over 21MB), they do need enough cache to hold a single tile. It’s much harder to estimate GPU L2 cache size from a die shot (especially with Apple’s asymmetrical design), but I wouldn’t be surprised of A9X’s GPU L2 cache is greater than A9’s or A8X’s.

Building A9X Big: 147mm², Manufactured By TSMC

Finally, let’s talk about the construction and fabrication of the A9X SoC itself. Chipworks’ previous analysis shows that the A9X is roughly 147mm² in die size, and that it’s manufactured by TSMC on their 16nm FinFET process.

At 147mm² the A9X is the second-largest of Apple’s X-series tablet SoCs. Only the A5X, the first such SoC, was larger. Fittingly, it was also built relative to Apple’s equally large A5 phone SoC. With only 3 previous tablet SoCs to use as a point of comparison I’m not sure there’s really a sweet spot we can say that Apple likes to stick to, but after two generations of SoCs in the 120mm² to 130mm² range, A9X is noticeably larger.

Some of that comes from the fact that A9 itself is a bit larger than normal – the TSMC version is 104.5mm² – but Apple has also clearly added a fair bit to the SoC. The wildcard here is what yields look like for Apple, as that would tell us a lot about whether a 147mm² A9X is just a large part or if Apple has taken a greater amount of risk than usual here.

A9X continues to be the largest 16nm FinFET ASIC we know to be in mass production at TSMC (we’ll ignore FPGAs for now), and while this will undoubtedly change a bit later this year once the next-generation discrete GPUs come online, I don’t think you’ll find a better example of how the contract chip manufacturing market has changed in a single generation. 4 years ago it would be GPUs leading the charge, but now it’s phone SoCs and a rather sizable tablet SoC that are first out of the gate. After almost a decade of catching up, SoCs have now reached the bleeding edge for chip fabrication, enabling rapid performance growth, but also inheriting the risks of being the leader. I won’t dwell on this too much, but I’m immensely curious about both what A9X yields are like as the largest FinFET ASIC at TSMC, and just how much of TSMC’s FinFET capacity Apple has been consuming with the production of A9 and A9X.

Finally, it's also interesting to note just how large A9X is compared to other high performance processors. Intel's latest-generation Skylake processors measure in at ~99mm2 for the 2 core GT2 configuration (Skylake-Y 2+2), and even the 4 core desktop GT2 configuration (Intel Skylake-K 4+2) is only 122mm2. So A9X is larger than either of these CPU cores, though admittedly as a whole SoC A9X contains a number of functional units either not present on Skylake or on Skylake's Platform Controller Hub (PCH). Still, this is the first time that we've seen an Apple launch a tablet SoC larger than an Intel 4 core desktop CPU.

SoC Analysis: On x86 vs ARMv8

Before we get to the benchmarks, I want to spend a bit of time talking about the impact of CPU architectures at a middle degree of technical depth. At a high level, there are a number of peripheral issues when it comes to comparing these two SoCs, such as the quality of their fixed-function blocks. But when you look at what consumes the vast majority of the power, it turns out that the CPU is competing with things like the modem/RF front-end and GPU.

x86-64 ISA registers

Probably the easiest place to start when we’re comparing things like Skylake and Twister is the ISA (instruction set architecture). This subject alone is probably worthy of an article, but the short version for those that aren't really familiar with this topic is that an ISA defines how a processor should behave in response to certain instructions, and how these instructions should be encoded. For example, if you were to add two integers together in the EAX and EDX registers, x86-32 dictates that this would be equivalent to 01d0 in hexadecimal. In response to this instruction, the CPU would add whatever value that was in the EDX register to the value in the EAX register and leave the result in the EDX register.

ARMv8 A64 ISA Registers

The fundamental difference between x86 and ARM is that x86 is a relatively complex ISA, while ARM is relatively simple by comparison. One key difference is that ARM dictates that every instruction is a fixed number of bits. In the case of ARMv8-A and ARMv7-A, all instructions are 32-bits long unless you're in thumb mode, which means that all instructions are 16-bit long, but the same sort of trade-offs that come from a fixed length instruction encoding still apply. Thumb-2 is a variable length ISA, so in some sense the same trade-offs apply. It’s important to make a distinction between instruction and data here, because even though AArch64 uses 32-bit instructions the register width is 64 bits, which is what determines things like how much memory can be addressed and the range of values that a single register can hold. By comparison, Intel’s x86 ISA has variable length instructions. In both x86-32 and x86-64/AMD64, each instruction can range anywhere from 8 to 120 bits long depending upon how the instruction is encoded.

At this point, it might be evident that on the implementation side of things, a decoder for x86 instructions is going to be more complex. For a CPU implementing the ARM ISA, because the instructions are of a fixed length the decoder simply reads instructions 2 or 4 bytes at a time. On the other hand, a CPU implementing the x86 ISA would have to determine how many bytes to pull in at a time for an instruction based upon the preceding bytes.

A57 Front-End Decode, Note the lack of uop cache

While it might sound like the x86 ISA is just clearly at a disadvantage here, it’s important to avoid oversimplifying the problem. Although the decoder of an ARM CPU already knows how many bytes it needs to pull in at a time, this inherently means that unless all 2 or 4 bytes of the instruction are used, each instruction contains wasted bits. While it may not seem like a big deal to “waste” a byte here and there, this can actually become a significant bottleneck in how quickly instructions can get from the L1 instruction cache to the front-end instruction decoder of the CPU. The major issue here is that due to RC delay in the metal wire interconnects of a chip, increasing the size of an instruction cache inherently increases the number of cycles that it takes for an instruction to get from the L1 cache to the instruction decoder on the CPU. If a cache doesn’t have the instruction that you need, it could take hundreds of cycles for it to arrive from main memory.

x86 Instruction Encoding

Of course, there are other issues worth considering. For example, in the case of x86, the instructions themselves can be incredibly complex. One of the simplest cases of this is just some cases of the add instruction, where you can have either a source or destination be in memory, although both source and destination cannot be in memory. An example of this might be addq (%rax,%rbx,2), %rdx, which could take 5 CPU cycles to happen in something like Skylake. Of course, pipelining and other tricks can make the throughput of such instructions much higher but that's another topic that can't be properly addressed within the scope of this article.

ARMv3 Instruction Encoding

By comparison, the ARM ISA has no direct equivalent to this instruction. Looking at our example of an add instruction, ARM would require a load instruction before the add instruction. This has two notable implications. The first is that this once again is an advantage for an x86 CPU in terms of instruction density because fewer bits are needed to express a single instruction. The second is that for a “pure” CISC CPU you now have a barrier for a number of performance and power optimizations as any instruction dependent upon the result from the current instruction wouldn’t be able to be pipelined or executed in parallel.

The final issue here is that x86 just has an enormous number of instructions that have to be supported due to backwards compatibility. Part of the reason why x86 became so dominant in the market was that code compiled for the original Intel 8086 would work with any future x86 CPU, but the original 8086 didn’t even have memory protection. As a result, all x86 CPUs made today still have to start in real mode and support the original 16-bit registers and instructions, in addition to 32-bit and 64-bit registers and instructions. Of course, to run a program in 8086 mode is a non-trivial task, but even in the x86-64 ISA it isn't unusual to see instructions that are identical to the x86-32 equivalent. By comparison, ARMv8 is designed such that you can only execute ARMv7 or AArch32 code across exception boundaries, so practically programs are only going to run one type of code or the other.

Back in the 1980s up to the 1990s, this became one of the major reasons why RISC was rapidly becoming dominant as CISC ISAs like x86 ended up creating CPUs that generally used more power and die area for the same performance. However, today ISA is basically irrelevant to the discussion due to a number of factors. The first is that beginning with the Intel Pentium Pro and AMD K5, x86 CPUs were really RISC CPU cores with microcode or some other logic to translate x86 CPU instructions to the internal RISC CPU instructions. The second is that decoding of these instructions has been increasingly optimized around only a few instructions that are commonly used by compilers, which makes the x86 ISA practically less complex than what the standard might suggest. The final change here has been that ARM and other RISC ISAs have gotten increasingly complex as well, as it became necessary to enable instructions that support floating point math, SIMD operations, CPU virtualization, and cryptography. As a result, the RISC/CISC distinction is mostly irrelevant when it comes to discussions of power efficiency and performance as microarchitecture is really the main factor at play now.

SoC Analysis: CPU Performance

Now that we’ve had a chance to take a look at A9X’s design and a bit on the difference between the x86 and ARM ISAs, let’s take a look at A9X’s performance at a lower level.

From a CPU perspective A9X is just a higher clocked implementation of the dual-core Twister CPU design we first saw on A9 last year. As a result the fundamentals of the CPU architecture have not changed relative to A9. However A9X relative to A8X drops down from three CPU cores to two, so among the factors we’ll want to look at is how Apple has been impacted by dropping down to two faster cores.

We’ll start things off with Geekbench, 3, which gives us a fairly low-level look at CPU performance.

Geekbench 3 - Integer Performance
	A9X	A8X	% Advantage
AES ST	1.17 GB/s	0.98 GB/s	19%
AES MT	2.85 GB/s	3.16 GB/s	-10%
Twofish ST	120.7 MB/s	64.0 MB/s	89%
Twofish MT	228.3 MB/s	182.7 MB/s	25%
SHA1 ST	1.03 GB/s	0.53 GB/s	94%
SHA1 MT	1.95 GB/s	1.48 GB/s	32%
SHA2 ST	205.8 MB/s	119.1 MB/s	73%
SHA2 MT	395.5 MB/s	330.6 MB/s	20%
BZip2Comp ST	8.95 MB/s	5.71 MB/s	57%
BZip2Comp MT	17.0 MB/s	16.6 MB/s	2%
Bzip2Decomp ST	14.7 MB/s	8.98 MB/s	64%
Bzip2Decomp MT	28.1 MB/s	25.2 MB/s	12%
JPG Comp ST	33.7 MP/s	20.6 MP/s	64%
JPG Comp MT	64.4 MP/s	60.8 MP/s	6%
JPG Decomp ST	89.2 MP/s	53.0 MP/s	68%
JPG Decomp MT	166.5 MP/s	153.9 MP/s	8%
PNG Comp ST	2.11 MP/s	1.35 MP/s	56%
PNG Comp MT	4.04 MP/s	3.82 MP/s	6%
PNG Decomp ST	31.5 MP/s	18.7 MP/s	68%
PNG Decomp MT	56.9 MP/s	56.3 MP/s	1%
Sobel ST	138.3 MP/s	82.5 MP/s	68%
Sobel MT	258.7 MP/s	225.6 MP/s	15%
Lua ST	3.25 MB/s	1.68 MB/s	93%
Lua MT	6.02 MB/s	4.60 MB/s	31%
Dijkstra ST	10.1 Mpairs/s	6.70 Mpairs/s	51%
Dijkstra MT	17.6 Mpairs/s	16.0 Mpairs/s	10%

The interesting thing about Geekbench is that as a result of being a lower-level test the bulk of its tests scale up well with CPU core counts, as the benchmark can just spawn more threads. Consequently I wasn’t entirely sure what to expect here, as this presents the tri-core A8X with a much better than average scaling opportunity, making it especially harsh on the A9X.

But what the results show us is that even by dropping back down to two CPU cores, A9X does very well overall. The single-threaded results are greatly improved, with A9X offering better than a 50% single-threaded perf gain in the majority of the sub-tests. Meanwhile even with the multi-threaded tests, A9X only loses once, on AES. Otherwise two higher clocked Twister cores are beating three lower clocked Typhoon cores by anywhere between a few percent up to 32%. In this sense Geekbench is something of a worst-case scenario, as real-world software rarely benefits from additional cores this well (this being part of the reason why A8 and A9 did so well relative to quad Cortex-A57 designs), so it’s promising to see that even in this worst-case scenario A9X can deliver meaningful performance gains over A8X.

Geekbench 3 - Floating Point Performance
	A9X	A8X	% Advantage
BlackScholes ST	14.9 Mnodes/s	8.52 Mnodes/s	75%
BlackScholes MT	28.2 Mnodes/s	24.9 Mnodes/s	13%
Mandelbrot ST	2.23 GFLOPS	1.27 GFLOPS	76%
Mandelbrot MT	4.27 GFLOPS	3.66 GFLOPS	17%
Sharpen Filter ST	2.10 GFLOPS	1.08 GFLOPS	94%
Sharpen Filter MT	4.01 GFLOPS	3.12 GFLOPS	29%
Blur Filter ST	2.68 GFLOPS	1.53 GFLOPS	75%
Blur Filter MT	5.08 GFLOPS	4.47 GFLOPS	14%
SGEMM ST	6.77 GFLOPS	4.12 GFLOPS	64%
SGEMM MT	12.7 GFLOPS	11.6 GFLOPS	9%
DGEMM ST	3.32 GFLOPS	2.02 GFLOPS	64%
DGEMM MT	6.21 GFLOPS	5.61 GFLOPS	11%
SFFT ST	3.52 GFLOPS	1.92 GFLOPS	83%
SFFT MT	6.67 GFLOPS	5.40 GFLOPS	24%
DFFT ST	3.21 GFLOPS	1.80 GFLOPS	78%
DFFT MT	6.02 GFLOPS	5.11 GFLOPS	18%
N-Body ST	1.41 Mpairs/s	0.78 Mpairs/s	81%
N-Body MT	2.69 Mpairs/s	2.34 Mpairs/s	15%
Ray Trace ST	4.99 MP/s	2.96 MP/s	69%
Ray Trace MT	9.56 MP/s	8.64 MP/s	11%

The story with Geekbench 3 floating point performance is much the same. Performance never regresses, even in multi-threaded workloads. In lightly threaded floating point workloads A9X is going to walk all over A8X, and in multi-threaded workloads we’re still looking at anywhere between a 9% and a 29% performance gain. This goes to show just how powerful Twister is relative to Typhoon, especially with A9X’s much higher clockspeeds factored in. And it lends a lot of support to Apple’s ongoing design philosophy of favoring a smaller number of high performance (and now higher-clocked) cores.

SPEC CPU 2006

Moving on, our other lower-level benchmark for this review is SPECint2006. Developed by the Standard Performance Evaluation Corporation, SPECint2006 is the integer component of their larger SPEC CPU 2006 benchmark. As was the case with SPEC CPU 2000 before it, SPEC CPU 2006 is designed by a committee of technology firms to offer a consistent and meaningful cross-platform benchmark that can compare systems of different performance levels and architectures. Among cross-platform benchmarks SPEC CPU is generally held in high regard, and while it is but one collection of benchmarks and like all benchmarks should not be taken as the be-all end-all of benchmarks on its own, it provides us with a very important look at CPU performance that we otherwise cannot get.

SPECint2006 is the successor to the SPECint2000 test we’ve been using periodically for the last couple of years now. Initially released in 2006, SPECint2006 is still SPEC’s current-generation CPU integer benchmark. We’ve wanted to switch to SPECint2006 for some time now, but have been held back by the overall low performance of tablet SoCs, which lacked the speed and memory to run SPECint2006 and to do so in a reasonable amount of time. However now thanks to the greater performance and greater memory of A9X, we’re finally able to run SPEC’s current-generation CPU benchmark on a tablet.

SPECint2006 is composed of 12 sub-benchmarks, testing a wide variety of scenarios from video compression to PERL execution to AI. This is a non-graphical benchmark and I believe it’s reasonable to argue that the benchmark set itself leans towards server high performance computing/workstation use cases, but with that said even if it’s not a perfect fit for tablet use cases it offers a lot of real-world tests that give us a good variety of different workloads to benchmark CPUs with. SPECint2006 scores are in turn reported as a ratio, measuring how many times faster a tested system is against the SPEC reference system, a 1997 Sun Ultrasparc Ultra Enterprise 2 server, which is based around a 296 MHz UltraSPARC II CPU.

CINT2006 (Integer Component of SPEC CPU2006):
Benchmark	Language	Application Area	Description
400.perlbench	C	Programming Language	Derived from Perl V5.8.7. The workload includes SpamAssassin, MHonArc (an email indexer), and specdiff (SPEC's tool that checks benchmark outputs).
401.bzip2	C	Compression	Julian Seward's bzip2 version 1.0.3, modified to do most work in memory, rather than doing I/O.
403.gcc	C	C Compiler	Based on gcc Version 3.2, generates code for Opteron.
429.mcf	C	Combinatorial Optimization	Vehicle scheduling. Uses a network simplex algorithm (which is also used in commercial products) to schedule public transport.
445.gobmk	C	Artificial Intelligence: Go	Plays the game of Go, a simply described but deeply complex game.
456.hmmer	C	Search Gene Sequence	Protein sequence analysis using profile hidden Markov models (profile HMMs)
458.sjeng	C	Artificial Intelligence: chess	A highly-ranked chess program that also plays several chess variants.
462.libquantum	C	Physics / Quantum Computing	Simulates a quantum computer, running Shor's polynomial-time factorization algorithm.
464.h264ref	C	Video Compression	A reference implementation of H.264/AVC, encodes a videostream using 2 parameter sets. The H.264/AVC standard is expected to replace MPEG2
471.omnetpp	C++	Discrete Event Simulation	Uses the OMNet++ discrete event simulator to model a large Ethernet campus network.
473.astar	C++	Path-finding Algorithms	Pathfinding library for 2D maps, including the well known A* algorithm.
483.xalancbmk	C++	XML Processing	A modified version of Xalan-C++, which transforms XML documents to other document types.

Although designed as a CPU-intensive benchmark, it’s important to note that SPECint2006 is officially labeled as “stressing a system's processor, memory subsystem and compiler.” The memory subsystem aspect is fairly self-explanatory – it’s difficult to test a CPU without testing the memory as well except in the cases of trivial workloads that can fit in a CPU’s caches – however the compiler aspect calls for special attention. As SPECint2006 is a cross-platform benchmark in the truest sense of the word, it’s impossible to offer a single binary for all platforms – especially platforms that had yet to be designed in 2006 such as ARMv8 – and, simply put, the moment you begin compiling benchmarks for different systems using different compilers, the performance of the compiler becomes a factor of benchmark performance as well.

As a result, and unlike many of the other benchmarks we run here, it’s important to note that compilers play a big part in SPECint2006 performance, and this is by design. Compiler authors can and do optimize for SPEC CPU, with the ultimate goal of giving the tested CPU the best chance to achieve the best possible performance in this benchmark; the compiler should not hold back the CPU. However in turn, all results must be validated, so overly aggressive compilers that generate bad code will be caught and failed. The end result is that in a cross-platform scenario with different binaries, SPECint2006 isn’t quite as apples-to-apples as our more traditional benchmarks, but it offers us a unique look at cross-platform CPU performance.

For our testing we’re using optimized binaries generated for Apple’s A8X/A9X SoCs and Intel’s Broadwell/Skylake processors respectively. The following compiler flags were used.

Apple ARMv8: XCode 7 (LLVM), -Ofast

Intel x86: Intel C++ Compiler 16, -xCORE-AVX2 -ipo -mdynamic-no-pic -O3 -no-prec-div -fp-model fast=2 -m32 -opt-prefetch -ansi-alias -stdlib=libstdc++

Finally, of SPECint2006’s 12 sub-benchmarks, our current harness is only able to run 10 of them on the iPad Pro at this time, as 473.astar and 483.xalancbmk are failing on the iPad. So the following is not a complete run of SPECint2006, and for the purposes of SPEC CPU are officially classified as performance estimates.

To start things off, let’s look at the Apple-to-Apple comparison, pitting A9X against A8X.

SPECint_base2006 - Estimated Scores - A9X vs. A8X
	A9X	A8X	A9X vs. A8X %
400.perlbench	25.0	14.1	78%
401.bzip2	17.6	11.5	54%
403.gcc	20.5	12.4	65%
429.mcf	18.7	N/A	N/A
445.gobmk	23.4	13.0	80%
456.hmmer	25.1	14.1	79%
458.sjeng	23.6	13.6	73%
462.libquantum	74.6	49.2	52%
464.h264ref	41.3	24.0	72%
471.omnetpp	10.3	8.0	29%

Unsurprisingly, A9X is leaps and bounds ahead here. The smallest gain is with 471.omnetpp, a discrete event simulator, where A9X holds a 29% lead. Otherwise A9X takes a significant lead, beating A8X by upwards of 80% in 445.gobmk, a Go (board game) AI benchmark.

Calling back to our iPhone 6s review for a moment, A9X has a much larger advantage vs. A8X with SPECint2006 as compared to A9 vs. A8 on SPECint2000. A good deal of this has to do with A9X’s significant clockspeed bump versus A8X, but at the same time this also illustrates how the newer SPECint2006 rates A9X and Twister even more highly than A8X/Typhoon. As we’ve seen time and time again, Twister is a much faster CPU core than the already fast Typhoon, and this is a big part of why Apple continues to top our ARM benchmarks.

Last but certainly not least however is our main event, A9X versus Intel’s Core M CPUs. As we’re finally able to run SPECint2006 on an Apple SoC, this is the first chance we’ve had to compare Apple and Intel CPUs using SPEC, so it’s exciting to finally be able to make this comparison.

At the same time this comparison not just for academic curiosity; as Apple has significantly improved their CPU design with every generation and has quickly moved to newer manufacturing processes, they have been closing the architecture and manufacturing gap with Intel. Twister and Skylake are fairly similar designs, both implementing a wide execution pipeline with a focus on achieving a high IPC, and in this latest generation of devices, coupling that with a fairly high 2GHz+ clockspeed. Over the years Apple and Intel have approached this problem from different angles – Apple built up from phones to tablets while Intel built down from desktops to tablets – but the end result is that the two have ended up in a similar place in terms of basic architecture design goals. Meanwhile from a manufacturing standpoint Intel is arguably still roughly a generation ahead with their 14nm FinFET process – naming aside, their transistors are smaller than TSMC’s 16nm FinFET – so Apple is the underdog from this point of view.

The burning question is of course is whether Apple’s CPU designs are catching up to the performance of Intel’s Core lineup, thanks to the continual iteration of architecture and manufacturing on the Apple side, versus the slower rate of growth we’ve seen over the last few generations with Intel’s Core lineup. The iPad Pro in turn finally gives us the opportunity to try to answer that question, as the faster SoC coupled with a form factor and TDP closer to regular Core M devices gives us the most apples-to-apples comparison yet.

To that end we have assembled a smorgasbord of Core M devices to compare to the iPad Pro and A9X SoC. Perhaps the most apple-to-apple comparison is the iPad Pro versus the 2015 MacBook; though approaching a year old, this is still Apple’s current generation MacBook, with our base model incorporating an older Broadwell-based Core M-5Y31. Also from the Broadwell generation we have an ASUS Transformer Book T300 Chi, which uses a high-end Core M-5Y71, to showcase the performance of Intel’s highest clocked Core M processors. Finally, from the latest Skylake generation we have the ASUS ZenBook UX305CA, which incorporates Intel’s base-tier Core m3-6Y30 CPU.

Finally, it should be noted that to keep testing as close as possible, all of these devices are passively cooled, and that as a result all of these devices are also TDP/heat throttling though much of the SPECint2006 benchmark. Ultimately what we’re measuring here is not the peak performance of each system, but rather its sustained performance under the TDP limitations of their respective designs. If unrestricted, undoubtedly all of these devices would score higher.

SPECint_base2006 - Estimated Scores - A9X vs. Intel Broadwell/Skylake
	A9X	Core M-5Y31 (2015 MacBook)	Core M-5Y71 (Asus T300 Chi)	Core m3-6Y30 (Asus UX305CA)	A9X vs MacBook %
Base/Turbo Freq	2.26GHz	0.9/2.4GHz	1.2/2.9GHz	0.9/2.2GHz
400.perlbench	25.0	21.7	28.5	24.4	15%
401.bzip2	17.6	14.6	19.6	15.3	21%
403.gcc	20.5	22.8	31.1	28.2	-10%
429.mcf	18.7	35.9	46.7	38	-48%
445.gobmk	23.4	16.9	23.7	18	38%
456.hmmer	25.1	43.9	61.9	48.1	-43%
458.sjeng	23.6	19.2	26.1	19.3	23%
462.libquantum	74.6	292	476	409	-74%
464.h264ref	41.3	38.4	49.7	37.3	8%
471.omnetpp	10.3	16.3	23.7	20.6	-37%

As this is a fairly dense lineup I’m not going to call out every figure, but let’s focus on a few key areas. First, on A9X versus the Core M-5Y31 (MacBook), the advantage flips between each device as each test hits upon different strengths and weaknesses of each CPU’s architecture. Overall each device wins half of the benchmarks, however the Core M powered MacBook wins by a larger average margin. In other words, the iPad Pro is competitive with the MacBook depending on the test, however on average it ends up trailing in performance.

Relative to the MacBook, the iPad Pro does best in 445.gobmk, the Go benchmark, while its largest deficit is with 462.libquantum. The latter is a particularly interesting case as the benchmark is very easy to vectorize, giving us perhaps our best look at the vector performance of Twister versus Broadwell, and how well their respective compilers can actually vectorize it. The end result has the Intel platforms solidly in the lead here, hinting that Intel still has better vector performance at this time.

Shifting gears to the Asus ZenBook UX305CA and its newer Skylake based Core m3-6Y30, to little surprise Skylake closes the gap with A9X in the benchmarks where Core M was losing, and pulls further ahead in the benchmarks where it was winning. Despite this the two systems split the number of wins at 5 each, but in the cases where the ZenBook is winning it’s very clearly winning. Overall Skylake sees some decent performance improvements relative to the Broadwell CPU in our MacBook – with the exact gains depending on the test – allowing it to widen the gap compared to the A9X. Overall A9X is still competitive in specific scenarios, but on average it definitely trails the Skylake Core m3.

Finally, going back to Broadwell we have the ASUS Transformer Book T300 Chi, which incorporates a high-end Core M-5Y71 processor. This is still officially a 4.5W TDP processor, and as a result this essentially measures Broadwell Core M’s best case performance. With a maximum CPU clockspeed of 2.9GHz as compared to the slower low-end Skylake and Broadwell CPUs, the T300 Chi unsurprisingly beats the iPad Pro in every single benchmark. At best the two are neck-and-neck with Apple’s best benchmark, 445.gobmk, but otherwise it’s a clear and very significant lead for Intel’s fastest Broadwell Core M processor.

In the end, what to take away from this depends on how you want to read the results and what you believe the most important CPU comparison is. As Apple doesn’t use multiple bins/clockspeeds of A9X processors, this muddles the comparison some since there’s a significant difference in performance between Intel’s fastest and slowest Core M processors, and at the same time Intel’s official list prices put every CPU except the top-bin Core m7-6Y75 at the same price of $281.

Ultimately I think it’s reasonable to say that Intel’s Core M processors hold a CPU performance edge over iPad Pro and the A9X SoC. Against Intel’s slowest chips A9X is competitive, but as it stands A9X can’t keep up with the faster chips. However by the same metric there’s no question that Apple is closing the gap; A9X can compete with both Broadwell and Skylake Core M processors, and that’s something Apple couldn’t claim even a generation ago. That it’s only against the likes of Core m3 means that Apple still has a way to go, particularly as A9X still loses by more than it wins, but it’s significant progress in a short period of time. And I’ll wager that it’s closer than Intel would like to be, especially if Apple puts A9X into a cheaper iPad Air in the future.

System Performance

While the iPad Pro is important for some of its tertiary features, without the performance to back it up the user experience will inevitably suffer. In order to try and get an idea for how the iPad Pro performs as a whole we turn to our suite of performance benchmarks that stress a number of different areas including the CPU, GPU, memory, and internal storage.

In the browser benchmarks, it's quite evident that the iPad Pro is far and away superior for browser performance compared to almost anything else on the market today, save the latest Surface Pros. This can be attributed to a few factors. One factor is that Safari has a number of optimizations that most Android browsers don't. The other factor is that the Twister CPU in A9X is just better suited for dealing with intense JavaScript, which is heavily reliant on single-thread performance. As the A9X only has two CPU cores that mostly rely on ILP to get acceptable levels of performance, the iPad Pro ends up doing impressively well in these benchmarks. I've found that this is also reflected in real world browsing performance, as the iPad Pro is less likely to choke on some popular JS-heavy tech websites than other devices with Chrome or an OEM-optimized browser. Quickly checking EmberJS performance tells pretty much the same story here as well.

In Basemark OS II 2.0, the iPad Pro pretty handily sets the record for performance by virtue of its GPU and CPU performance. For whatever reason there's some sort of hang-up in web browsing performance, which could be due to some sort of code path that doesn't respond very well to additional ILP. Whatever the case, performance isn't too far behind the iPad Air 2 here by virtue of higher IPC and clock speeds. Overall, the iPad Pro seems to be quite performant for everyday tasks.

System Performance Cont'd

Continuing on with our more game-like benchmarks, tests like 3DMark and GFXBench are supposed to replicate gaming workloads to help determine relative performance in most common 3D games. In the case of the iPad Pro, the GPU is a 12 cluster variant of the PowerVR Series7XT GPU architecture. This is double the number of clusters relative to the A9’s GPU, which should prove to be quite impressive judging by the GPU performance that we saw in the iPhone 6s.

The iPad Pro manages to maintain superiority in 3DMark, but we're really starting to see the limitations of this test. The physics test generates non-sequential data structures with memory dependencies, which can penalize devices with lower core count and clock speed, but the workload is able to be spread across multiple cores to exploit TLP, which benefits devices with more real cores, or virtual ones (hyperthreading). We also see that the graphics test isn't really scaling well at this point as it's just too light to take advantage of the full potential of the A9X GPU. This likely also explains why the iPad Pro isn't closer to the Surface Pro 4 in performance on this benchmark, given what we know about A9X's GPU.

In GFXBench we can see the major benefits that really come with the larger GPU. It's pretty obvious here that clock speeds are basically identical when comparing the A9 GPU and A9X GPU as the scaling is almost perfectly double. In this benchmark the iPad Pro quite handily beats the Surface Pro 4, but it's important to keep in mind that the Surface Pro 4 is running a higher level of precision and that the iPad Pro is running OpenGL ES rather than OpenGL in this test, so it isn't strictly apples-to-apples (nor is such a thing truly possible at this time). Overall though the GPU of the iPad Pro is incredibly impressive, and I doubt that anyone will really have issues with gaming performance on this device.

NAND Performance

At this point it’s pretty well understood that storage performance can often be a gating factor in performance. Although caching is an amazingly effective method of hiding memory latency, for the first hit it’s mandatory to miss the cache unless you’ve managed to prefetch the data in question. The other issue where storage performance becomes obvious are cases where it’s necessary to commit data to storage first. Some cases where this is going to be obvious is app installation or iCloud restores, especially when network performance is at the point where installation can actually be gated by writing to disk rather than downloading from the network.

In the case of the iPad Pro, Apple claims that they’ve implemented a storage controller comparable to some desktop SSDs. It turns out that this controller is a familiar one, as the storage controller identifies itself as the APPLE SSD AP0128K in the case of this review unit. It turns out that everything about this SSD is identical to what we saw in the iPhone 6s as well, down the use of Hynix for at least one of the NAND vendors and the hybrid SLC/TLC architecture discussed in previous articles. In order to test how this storage solution performs we once again use Eric Patno’s StorageBench, which provides a rough analogue to AndroBench 3.6.

It turns out that in this test, performance is basically identical to the iPhone 6s. This isn’t quite the equal of something like the Surface Pro 4’s PM951 SSD, which has the advantage of more NAND dies working in parallel, but given that the iPad Pro PCB size isn’t going to be anywhere near that of the Surface Pro 4 it’s likely that this is a concession to gain better battery life. I definitely wonder what performance would be like relative to a Surface Pro 4 if the iPad Pro had a 512GB SKU, but given that the iPad Pro tops out at 128GB this isn’t really a question with a relevant answer.

Battery Life

Battery life is important beyond any doubt. No one wants a tablet or phone that can only spend three hours away from a charger before it dies, no matter how good the device is. While such battery life might be incredible for a desktop replacement or anything else that realistically spends most of its life plugged into a charger, mobile devices are usually carried on the go and used far away from a charger for significant amounts of time. Probably the ultimate example of this is travel, where one might use a tablet to watch movies and browse the internet for a few hours over the course of a flight.

As a result, a significant portion of our reviewing efforts are devoted to determining battery life. In order to quantify battery life, there are inevitably a lot of test cases to cover. Some people might spend most of their time in an e-reader app, others might spend most of their time playing games or similarly intensive tasks on their phones. There’s no real standard for usage, so a tablet that might last a day for one person could last a week. As a result, the goal of our testing is to provide a useful relative comparison. In order to do this, we attempt to equalize for variables like display brightness by setting all displays to 200 nits for battery life testing. Due to the inability to completely eliminate the variables that come with live network testing, we also use strong network reception with high throughput on LTE to ensure that things like power amplifiers are either at a low power setting or bypassed entirely.

Our first test is the venerable web browsing test, in which we load a selection of web pages from full charge until the device shuts off from lack of battery charge. In WiFi battery life is pretty much identical to the iPad Air 2, which might be surprising given that the battery is only 41% larger. That might sound like a lot, but the display of the iPad Pro is 77% larger at the same 264 PPI pixel density, which means that there’s a pretty sizeable efficiency gap between the iPad Air 2 and iPad Pro. The improved display and SoC are likely to be the main reasons for this, as the 20nm SoC process that was used to make the A8 SoC was quite leaky due to its traditional planar transistor structure compared to the FinFET process used in the A9X.

Interestingly, for whatever reason when re-running the same test on LTE battery life is noticeably different when compared to the iPad Air 2, where LTE and WiFi battery life were relatively close. I suspect that RF power is pretty similar between the two devices, but due to efficiency improvements on the display/SoC side the difference in battery life due to additional RF power consumption is magnified.

The more interesting test result that I encountered over the course of battery life testing was our tablet video rundown test. For whatever reason, web browsing clearly lasts a decent amount longer. It's pretty unlikely that the web browser has a lower SoC load when video is basically entirely dependent upon fixed function hardware decode. The most plausible explanation here for me is that we're seeing differences that arise from panel self-refresh, which can kick in on our web browsing test while the same definitely doesn't hold for our video test, which basically requires at least 30 FPS refresh rate continuously for the entire duration of the test. Overall that this makes the iPad Pro worse for content consumption, given Apple's content creation goals, is an unexpected turn of events.

Moving on to the more SoC-bound tasks, we can start by looking at Basemark OS II, which is basically a CPU power virus that can be used to examine the upper bound for device TDP, in addition to nominal sustained CPU load. It’s evident from this test and some back of the envelope calculation that total device TDP excluding display power is roughly 5W, which is about right given the size of the device. This suggests that the A9X can be directly compared to Intel’s Core M in both performance and power, for better or for worse. Performance here is good, with relatively low throttling due to the use of a FinFET process and solid implementation of the Twister architecture.

In our GPU throttling test, the A9X has effectively made it impossible to actually use T-Rex as a throttling test as it’s essentially pegged at vsync for the entire duration of the test. The iPad Pro also lasts a similar amount of time here as on the Basemark OS II test, which suggests that this test is still reaching TDP limits for the GPU, even if it doesn't manifest in the form of reduced performance.

Charge Time

While battery life is important, any time you’re dealing with a mobile device the time it takes to charge the battery is important as well. The usual example here is travel, but simply forgetting to plug in a device overnight can show the importance of charge rate. In the case of the iPad Pro, Apple ships it with their usual 12W charger. One might be tempted to suggest that the battery would be charged in about 3.5 hours, but it’s necessary to get the data and avoid speculation on something like this. In order to test how quickly the iPad Pro charges, we measure the difference in time between first plugging in a fully discharged tablet and when the charge is complete based upon power draw at the AC adapter.

Interestingly, the iPad Pro takes a pretty significant amount of time to charge, at over a full hour longer than the iPad Air 2. While some might be okay with this, it’s definitely a sore spot for the iPad Pro as a higher voltage charger would be able to charge the device at a more acceptable rate. I’m not really sure why Apple decided to go this route, but there’s really no clear solution here unlike the case of the iPhone 6s Plus. The charger also definitely isn’t enough to ensure that you’re always charging the iPad Pro while in use either if the SoC is in overdrive/turbo states as thermally constrained power draw is already around 9-10W.

Despite the long charge time, overall the iPad Pro is quite mobile. However, it does regress somewhat relative to the iPad Air 2 due to its longer charge time, even if battery life is equivalent. Depending upon your use case though it might be difficult, if not impossible to tell the difference.

Display

With the iPad Pro, one of the main points of interest is its display. Although there are other elements to the iPad Pro like the stylus and the keyboard, the display is really the centerpiece of this tablet, especially when neither the Apple Pencil nor the Smart Keyboard come included with the iPad Pro itself. I think it goes without saying that everyone wants to have a great display on a tablet, but what determines a great display is often in question.

While it’s obvious that less reflectance is better, as is higher contrast and maximum brightness, things like gamma and color reproduction are often subjective as the same color will often look different to different people. In order to try and deal with this issue, we focus on testing all mobile displays to the same color accuracy standards. For now, the industry standard gamut is the sRGB gamut, along with power 2.2 gamma. Although the sRGB gamut is relatively limited compared to something like DCI-P3 or Rec. 2020, it remains an industry standard when compared to what exists on the market today. In order to test how well a display meets these standards in addition to other criteria, we use an i1Pro2 spectrophotometer for accurate color measurements along with an i1Display Pro for accurate contrast measurements. In order to organize this data into a readable format we use SpectraCal’s CalMAN 5 with a custom workflow.

In the case of the iPad Pro, it’s obvious that the architecture of the display is different from what we’ve seen in mobile devices before. Due to the sheer resolution, it seems that Apple is electing to use embedded Display Port (eDP) instead of the more traditional MIPI DSI interface used in smartphones. We’ve seen a number of smartphones and tablets this year ship with an 8 lane MIPI DSI configuration which allows for a theoretical maximum of 2715x1697 for about 4.6MP, but the 2732x2048 resolution of the iPad Pro means about 20% more pixels than what a 2 port MIPI DSI configuration can handle.

Source: design-reuse.com

By comparison, eDP has been able to support 4K at 60 Hz or higher for quite some time. This is self-evident by looking at the number of laptops launched with a 4K display. With the iPad Pro, Apple claims that they’ve implemented their own custom timing controller or TCON. Some digging through the system files seems to corroborate these claims as there are numerous references to an Apple Agile DP Display SAC Controller. That’s a mouthful, but Agile seems to be the internal name for this controller, and DP seems to be a reference to DisplayPort, while SAC is likely a reference to Slow Adaptive Clocking.

Slow Adaptive Clocking is something that there's very limited public information on at this time. My best guess here is that this is actually related to the variable refresh rate technology that Apple is implementing in their custom TCON. On the surface this technology seems to bear a lot of resemblance to G-Sync or FreeSync, but rather than varying refresh rate to fit the GPU’s rendering rate the refresh rate only has two distinct settings at 60 Hz and 30 Hz depending upon whether the content on the display would benefit from the higher refresh rate. It’s likely that at least part of the reason why this is possible is the use of indium gallium zinc oxide (IGZO) TFTs which don’t leak current in the off state. This means that when there is a longer period of time between display refreshes, the liquid crystal retains its state rather than fading towards its original state of either completely open or closed to the backlight.

Source: semiconportal.com

In addition to this adaptive refresh rate, the TCON supports panel self-refresh which is hardly news, but given that we’ve seen phones and tablets in this year ship without panel self-refresh it’s worth mentioning.

The panel itself also appears to have dual domain pixels and a conventional RGB stripe. Viewing angles as a result are quite good. The cover glass also contains the AR coating first introduced with the iPad Air 2, which cuts reflectance roughly in half relative to a display that doesn’t have such a coating. This effectively doubles outdoor contrast, so it’s great for outdoor use.

In our standard test of brightness and contrast, it’s evident that Apple has moved to a new generation of display for the iPad Pro as the maximum brightness is mildly improved relative to the iPad Air 2. The real change here though is that contrast is dramatically improved over the iPad Air 2.

This is likely due to the use of photoalignment for the liquid crystals, which helps the liquid crystal to have a more consistent orientation. For those that aren’t really familiar with the particulars of how light polarization and polarizers work, part of the problem is that when a voltage is applied to change the structure of the liquid crystals parts of the liquid crystals won’t necessarily change in structure appropriately. In order to assist with this process a film is applied which gains a particular orientation when exposed to UV light in a specific way. This helps to get the liquid crystals to all align in the same direction, which improves contrast as a result. Of course, contrast isn’t the dark, inky blacks that you'll get with AMOLED but it'll still be quite impressive for normal use.

Source: eetimes.com

Moving on to our grayscale test, the iPad Pro does impressively well overall with well-controlled gamma but tending slightly towards a colder color balance. I’m not sure whether this is because of backlight efficiency concerns due to the use of blue LED with yellow phosphor in the backlight or because people seem to prefer colder white balances in general, but it’s there nonetheless. The cold color balance might affect some particularly color critical work but even for medical use I suspect it shouldn’t be a serious problem.

In saturations, the iPad Pro is basically perfect. There is some mild undersaturation of red, but I basically see no reason to try and find some method of personally calibrating the display.

In the Gretag MacBeth ColorChecker test, color error is once again basically nonexistent. Anything with red appears to be mildly undersaturated but the error is going to be almost impossible to notice.

Overall, the iPad Pro display is probably one of the best available on the market today. The Galaxy Tab S2 display is comparable in overall accuracy and has superior contrast, but the iPad Pro has noticeably higher brightness for all content above 50% APL and in any scenario with a lot of ambient background light the AR coating will help a lot with improving effective contrast and general readability. Although pixel density is equivalent to the iPad Air 2, the sheer size of the display means that the viewing distance is increased and therefore the perceived resolution. The display looks great in person, and unless your single point of consideration for display performance is contrast I think it’ll be hard to be disappointed with the iPad Pro display.

Apple Pencil

At this point it probably goes without saying that Apple Pencil has been one of the major points of focus for this tablet. With the iPad Air 2, I noted that a proper stylus and keyboard would go a long way towards making the iPad more productivity focused. It turns out that Apple’s solution to the stylus part of the equation is a custom design that they call the Apple Pencil.

As best as I can tell, this stylus is at least somewhat capacitive-based. If Apple’s marketing material is accurate, it mentions a change from the 120 Hz sampling rate of the capacitive touch screen in normal use to 240 Hz when the stylus is detected. In addition to simple touch, the stylus measures pressure, azimuth, and altitude. When discussing azimuth, we’re basically looking at the angle that the stylus makes with the plane of the display, while altitude is the angle that the stylus makes relative to the normal of the display.

Charging the stylus is pretty simple. Included in the box is a female to female Lightning connector, so you can use a Lightning to USB cable to charge the stylus with either an AC adapter or a powered USB port. Of course, there’s also the case where you’re trying to charge the device on the go, in which case the stylus can be charged directly from either the iPad Pro or an iPhone. A lot of people have pointed out that this is a rather inelegant method of dealing with charging on the go, but given that the primary method of charging is through a Lightning connector I don’t really see any other solution to this problem, especially without compromising the ergonomics that come with the current design. Charging the stylus happens quickly enough that I never felt that it was a limiting factor in usage.

Apple Pencil itself is a comfortable instrument to write with. Unlike most styluses on the market designed to fit in a tablet or smartphone the body has a sufficiently large diameter that gripping it isn’t difficult for extended periods of time. The pencil also has an uneven weight distribution, which means that it won’t roll off of tables, though not so uneven that it's noticeable in the hand. The one problem worth noting here is that Apple Pencil is glossy plastic. After extended use I noticed that finger oil and lint had a tendency to produce an uncomfortable sensation. A matte soft touch texture may make more sense here, but that would introduce additional issues with the finish wearing off with extended use.

Credits to Nina Ling and Cory Ye respectively

Of course, the important part here is writing with the stylus. Although I’ve already discussed the application of note taking in class before, in the time since my initial remarks on the iPad Pro I decided to do an entire project report on Apple Pencil in order to get a better feel for the stylus and its usability. This was done for a digital logic project in which we were required to draw out finite state machine diagrams, truth tables, block diagrams, and other portions of the design. I would estimate that over the course of this project, I spent at least 4 hours a day using the iPad Pro for 2-3 days.

One of the most immediate observations I had was that in some ways, the iPad Pro with Apple Pencil is far and away superior to pencil and paper. Even using the rather spartan Notes app this became clear. There were multiple cases throughout this project where a change that would have been difficult to make with pencil and paper was relatively simple to do so with Apple Pencil and the iPad Pro. For example, in cases where extra precision was needed it was possible to zoom in to erase a portion of text precisely. When an erasure was done poorly or on accident, reverting it was trivial as well. The project report, which eventually spanned 16 pages in length was synced to iCloud and was accessible from laptops and smartphones, which meant that it would be difficult, if not impossible to lose accidentally. It’s also noticeably more convenient to carry around an iPad Pro rather than a folder filled with paper. Along the same train of thought, drawing long truth tables with the straightedge function of the Notes app is much easier than carrying around a ruler everywhere. It was also great to have the project requirements and the notes application open side by side, which meant that there wasn’t a need to print out the project spec.

One notable problem that I did encounter with the Notes app is when the work I was doing spanned more than one page/sketch. An example of this would be cases where I would have to construct a state table based upon a state diagram that was sketched based upon the project requirements. If the state diagram was on a separate page, then I would simply have to switch back and forth between the two sketches or save the relevant sketch as an image to view in the gallery application, which felt a bit clunky.

The other issue, as it turns out, was getting the sketches off of the iPad Pro onto my laptop once I was ready to turn my work in. On the plus side, because all of my sketches were already digitized there was no need to locate a scanner and generate images or PDFs. However, the Notes app felt noticeably constrained in terms of export options. For example, there was no way of turning the 16 sketches I had drawn into a PDF on the device. I also discovered that as of iOS 9.2 attempting to save all sketches as images was broken as only 5 of the 16 sketches were saved to the gallery. Exporting the sketches by attaching them to an email was also unacceptable as the email export resolution was nowhere near native resolution. In the end, in order to get all of the sketches I had made off of the iPad in full resolution I had to manually select each sketch and save it to the gallery, before uploading all of the images to Dropbox. From my laptop, I could then put all of the images together into a PDF or some other acceptable format for submission.

However, despite these issues I found that the iPad Pro was remarkable for doing what very few tablets have really succeeded at. The iPad Pro actually feels comparable to pencil and paper to the extent that I never once felt like I wanted to go back to pencil and paper while doing the final project. Both the display and the stylus have sufficient resolution to the extent that precise work is easily achieved. The feel of the stylus feels like a good pen or pencil, without odd weight distribution problems.

Latency is also exceptionally low compared to most consumer solutions. Out of curiosity, I borrowed a Wacom Cintiq connected to a Macbook Air with an Intel i5 4250U CPU (Haswell 1.3/2.6 GHz) to do a basic latency comparison. Using Adobe Photoshop on the Wacom Cintiq and Adobe Photoshop Sketch on the iPad Pro and a high speed camera, I attempted to characterize latency by using a simple pen tool (3 px, full flow) by measuring the delta in time from when the pen was at a specific point and when inking reached the same point.

Stylus Latency - iPad Pro vs. Wacom Cintiq
	iPad Pro (Photoshop Sketch)	Wacom Cintiq (Photoshop)
Latency	49ms +/- 4ms (3 frames)	116ms +/- 4ms (7 frames)

After a few trials I measured an approximate latency for the iPad Pro of roughly 49ms or 3 frames of delay, while the Wacom Cintiq in this configuration had roughly 116ms or ~7 frames of delay. It’s worth mentioning here that the camera I used was recording at 240 FPS, so these figures could be off by around 4ms even before accounting for human error. Although the Cintiq 22 HD does have higher latency, I wouldn’t put too much into this as it’s likely that a more powerful computer driving the display would narrow, if not eliminate the gap entirely.

For reference, I estimated the Surface Pro 3 to have about 87 ms or 5-6 frames of delay, and the Surface Book to have about 69 ms or around 4 frames of delay. However, in the case of the Surface devices I was using Fresh Paint, which is a drawing application that isn't exactly comparable to Photoshop but is sufficient for comparison purposes. To give an idea for how much the application has an effect on latency, the Apple Notes app has roughly 38 ms or around 2 frames of latency from when the stylus tip passes over one point to when the inking reaches the same point.

While not strictly hardware, the software equation is really a critical part here as there are actual applications for the Apple Pencil which make it possible to use right now. An example of this would be OneNote, uMake, and Adobe Comp CC/Photoshop Sketch. Some of these applications work shockingly well like Photoshop Sketch, while something like OneNote feels relatively sparse by comparison as pretty much the only thing you can do with the stylus is draw simple lines with pressure sensitive thickness, with some automatic conversion of drawings to basic geometric shapes. With the right software, I can easily see the iPad Pro completely displacing traditional note-taking in light of obvious advantages that would come with OCR and digitizing notes for easy search.

Smart Keyboard

The other half of what makes the iPad Pro worth talking about is the Smart Keyboard. For those that are unfamiliar with how this keyboard works, in essence it’s really a flip cover that happens to hide a keyboard inside of it. This is yet another thing I mentioned that the iPad really needed to improve its potential as a productivity tool.

I’m going to go ahead and spoil this section by saying that while the Smart Keyboard is worthwhile if you’re typing out more than a paragraph, this feels like one of the clunkier aspects of the iPad Pro.

However, the important question is how I got to that conclusion. Going over the user experience of the keyboard is a pretty simple matter. Attaching the cover to the tablet works the same way it always does, which is accomplished by placing the edge of the cover onto the edge of the tablet which also contains the Smart Connector. There are some strong magnets that help with alignment here, and provide the positive pressure needed to ensure that the data and power pins of the Smart Connector are firmly connected to the keyboard.

Once the cover is connected, setting up the keyboard is done by folding it out and doing some origami until the tablet is docked into the right place on the keyboard, which has a noticeable notch to it. Aligning this despite the strong magnets does take some work, as it seems that unless the cover is setup correctly the keyboard isn’t enabled at all.

If you’re trying for precision, I would say that there’s roughly a 4-5 second time delay from the moment that you decide that you need to use the keyboard to actually using it. In addition to this time delay, the keyboard is rather precarious and is basically only stable when you’re using it on a table. While gravity can keep the whole setup somewhat stable on your lap when the display is leaning backwards, if the display starts leaning forwards there’s really nothing stopping it from collapsing and detaching from the cover, as while the magnets are strong enough to hold the tablet in a static state, they aren’t strong enough to hold the tablet if there’s the additional force of decelerating the tablet as it falls. As a result, the angles that the keyboard and tablet can hold relative to each other is fixed.

To be fair, once the keyboard is set up and it’s in a stable position, typing on the tablet is a great experience. The Surface Pro 3 was decent in my experience, but the touchpad with its lack of strong palm rejection made for some frustrating experiences. In this respect, the iPad Pro does a lot better, to the extent that I didn’t have any trouble doing things like typing up long forum posts or various sections of this review. Key travel is short, but there’s good haptic feedback and the layout of the keyboard doesn’t have any strange issues that seem to happen so often to so many tablet keyboards. Something like the Pixel C just doesn’t even compare here, especially because due to the use of Bluetooth it’s absolutely useless in an apartment or any remotely dense environment where the 2.4 GHz spectrum is crowded to the point that it approaches being unusable.

However, despite this significant setup time for the keyboard cover, pretty much the only value for the keyboard cover is text input. Due to the ergonomics of a near-vertical touch screen it’s really not something that can be used for extended periods of time as once you’re done with text input to comfortably use the touch screen you really need to break down the keyboard and revert it back to a simple tablet.

I’ve spent a lot of time thinking about the conundrum of the keyboard when it comes to these tablets, and honestly I don’t think anyone has figured out the right way of doing things yet. I think the Pixel C in form is a step in the right direction, but the execution is unfortunate to say the least. The iPad Pro touchscreen keyboard has the size to allow for touch typing, but the utter lack of position feedback makes it difficult to know where to keep your hands and because touching the display means inputting a character it’s necessary to awkwardly keep your hands right above the glass of the display. The heart of the issue here is that it’s necessary to have an input method where it’s easy to keep your fingers resting on the home row of the keyboard, with clear haptic feedback for input and some indication of where the keys are. It’s also necessary to make sure that this keyboard is easily accessible when it’s needed but quickly stowed away when it isn’t.

I can’t help but wonder whether the better solution here would be something like Lenovo’s Yoga Pro design, but with a different method of execution. Instead of making the two halves a single unit, the keyboard portion should be easily and quickly detached with the smart connector held within the hinge. Rather than a traditional laptop keyboard, something more like the current Smart Keyboard would make a lot of sense. However, I suspect that in doing this a traditional flip cover would no longer make sense as the keyboard would really become an integral part of the user experience once properly integrated. We can talk about how touch-only is a faster and more convenient experience, but this really only applies to navigation as while I can type at about 40 words per minute without issue on a phone or tablet trying to reach 100 words per minute is hard to say the least.

Overall, I should make it clear that the iPad Pro’s Smart Keyboard is not a bad keyboard by any means. When I’m able to just focus on typing, the user experience far exceeds pretty much anything else I’ve tried in the industry. The problem is that as the Smart Keyboard starts to approach the point where I can actually use it, I start to really notice all of the flaws that the implementation has. In this case, the two major issues that really need to be solved here are speed to deploy/stow and lap stability. While a lot has been made of the iPad Pro’s inability to have adjustable viewing angles realistically it only needs two viewing angles, similar to how the Smart Cover only has two viewing angles. If the Smart Keyboard can feel like it appears and disappears almost instantly and can be used without a table effectively, it would probably be the ideal solution to the keyboard problem that tablets face.

Software UX

For those that are unfamiliar with our other articles, we reviewed iOS 9 at its release back in September. If you aren’t familiar with what has changed in the move from iOS 8 to iOS 9 I highly recommend reading it as for the most part I have nothing new to say in the context of what was covered in that review. Instead of treading old ground, it’s worth discussing the specific aspects of the user experience that are unique to the iPad Pro.

The first, and perhaps most obvious change is the display size and resolution. While the aspect ratio is the same as the iPad Air, the significantly increased display size and resolution also affects applications. For the most part I haven’t noticed any issues here. However, in some cases there are still applications that haven’t been properly redesigned for the larger display, so they end up simply being purely upscaled versions of applications designed to fit 7.9 and 9.7 inch displays. This tends to look fairly ugly in my opinion but it does work without issue when dealing with backwards compatibility.

In cases where applications are updated to fit the iPad Pro, designs are generally well-executed and take advantage of the additional screen real estate. It’s probably not a surprise to know that most applications fall under this category, but it’s worth mentioning at any rate.

The larger display size also greatly enhances the utility of split-screen multitasking on the iPad Pro, as it’s generally quite useful to be able to run two almost iPad Air-sized apps simultaneously on the iPad Pro. As discussed in the Apple Pencil section of this review, being able to read a PDF and take notes/do problem sets based upon a document opened in Safari is incredibly useful and helps with productivity. There are other applications here to be sure, but I think an education setting was where I found the most value. However, it's worth mentioning that the multitasking UI feels like it isn't really designed for a future where hundreds of applications will occupy the slide-out multitasking menu.

For the most part, iOS is smooth and performant on the iPad Pro. However, there are a few notable cases where I did notice frame drops. For whatever reason, this seems to be basically limited to the Notes application. It seems that as time has gone on it has become increasingly difficult for anyone shipping a mobile OS to make everything smooth all the time, likely a product of their increasing complexity and larger code base.

Overall, I don't have as much to say here. When the only two competing tablet operating systems worth discussing in comparison to iOS are either neglected (Android) or heavily reliant upon legacy applications that really need a mouse and keyboard to be used properly (Windows), iOS stands alone as basically the only touchscreen OS worth using. I don't think the solution to the problem of the keyboard with the iPad Pro means that it needs a touchpad, nor should using both keyboard and touch simultaneously in the deployed mode be the dominant method of interaction. Trying to do the former is basically just emulating a really terrible laptop, while the latter makes for poor ergonomics almost universally.

While it may be appealing to make a tablet that is also a laptop due to the nature of legacy Windows applications, trying to make such a convergence device is a great way to make either a compromised laptop or a compromised tablet. The other half of the functionality is almost never going to be used in practice if my experiences with Surface Pro are anything to go by. Android showed arguably even more promise than iOS as a tablet OS due to its more traditional computer than appliance OS structure, for whatever reason the promise that came with the structure of Android didn't pan out in execution.

As a result, the iPad line stands alone in software, for better or for worse.

Camera

While it’s pretty much a universally terrible idea to use a tablet as your primary camera, for something like video chat or in an emergency it’s better to have one than not. In the case of the iPad Pro, the camera is essentially identical to what we saw with the iPad Air 2, which is to say an 8MP 1.1 micron 1/4” sensor, with an F/2.4 aperture and 3.3mm focal length, which translates to a 35mm equivalent focal length of 31mm. There’s no PDAF or anything fancy going on here, so it’s pretty much a guarantee that the camera is the exact same module that we saw with the iPad Air 2. The front facing camera is still a 1.3MP F/2.2 2.65mm focal length module, which leads me to believe that it too is shared with the iPad Air 2. I honestly don’t see any difference between the iPad Air 2 and iPad Pro cameras, so rather than spending time dwelling on those this comparison will be focused upon how it compares to popular smartphones and the tablet competition. As I don’t have a tripod mount that can actually fit the iPad Pro, I’ve elected to forgo some of our standard latency tests to avoid presenting data with confounding variables.

Daytime Photography Scene 1

iPad ProGoogle Pixel CiPhone 6iPhone 6s

In our first daytime scene the iPad Pro is actually not that far off from the iPhone 6s. If you look closely it’s obvious that there is less detail to be seen, but it’s honestly quite difficult to see the difference. Relative to the iPhone 6, detail is almost identical. For a camera that should basically be never used for the kinds of photos I’m taking for this review, the camera will work well in a pinch. By comparison the Pixel C is rather disappointing. Even in this ideal condition, detail is visibly worse when compared to the iPad Pro. I’m not sure whether this poor showing is caused by camera shake or AF issues but in general the AF system for the Pixel C had some pretty noticeable issues in general. There are also some obvious problems with color noise despite base ISO, which is shocking.

Daytime Photography Scene 2

iPad ProGoogle Pixel CiPhone 6iPhone 6s

In the interest of trying to collect more than one data point for presentation in the review, I tried another scene. Once again, the iPhone 6s shows a minor resolution lead and the iPad Pro is pretty close to the iPhone 6 here. By comparison while there isn’t any obvious weirdness going on the Pixel C clearly has less detail and a noticeable amount of color noise, which is surprising even for a tablet camera. Color noise is one of the most distracting things in any photo, so I’m always concerned when any mobile device has a camera where the JPEG output shows color noise.

Low Light Photography Scene 1

iPad ProGoogle Pixel CGoogle Nexus 9iPhone 6iPhone 6siPhone 6s Plus

Low Light Photography Scene 2

iPad ProGoogle Pixel CGoogle Nexus 9iPhone 6iPhone 6siPhone 6s Plus

Moving on to the low light testing, we clearly see the disadvantage that comes with smaller pixel sizes. The iPad Pro is just clearly worse than the iPhone 6 and 6s here. The 6s Plus is the clear winner of this test. While the iPad Pro has dark output, it’s miles better than the Pixel C and Nexus 9, both of which show enormous amounts of color noise. The Tegra X1 and K1 ISP for whatever reason is struggles with doing things like hot pixel compensation in low light, as in the dark areas of the photo there are obvious bright speckles of pixel noise.

Low Light Photography Scene 3

iPad ProGoogle Pixel CGoogle Nexus 9iPhone 6iPhone 6siPhone 6s Plus

In another low light scene we see the same sort of ordering that was in the previous scene. The iPad Pro is acceptable here, but the iPhone 6, 6s, and 6s Plus are all clearly superior. However, the iPad Pro is clearly superior to the Pixel C and Nexus 9 on the basis of better detail and noise reduction. Unlike most smartphones I don’t really see a huge difference in how well everything freezes motion here, but I suspect this might just be because the entire image for the Pixel C and Nexus 9 is so lacking in detail.

Video

1080p30 Video

iPad Pro 1080p30Pixel C 1080p30iPhone 6s 1080p30iPhone 6s Plus 1080p30

Looking at video performance, the iPad Pro noticeably lags behind the iPhone in feature set, which isn't entirely unsurprising given that the camera on any tablet should be strictly reserved as a fallback for when you can’t get to a smartphone or literally anything else. 1080p30 is encoded with H.264 high profile at 17 Mbps, with around 82 Kbps single channel AAC audio. For the most part, quality here is actually comparable to the iPhone 6 and 6s in daytime, with a noticeably tighter crop due to the longer 35mm equivalent focal length. The iPhone 6s Plus is again the obvious winner here though, due to its use of OIS in video. By comparison, the Pixel C shows clearly less detail, and the higher contrast leads to worse detail in areas like the road and in shadows.

Slow-Motion Video

iPad Pro 720p120iPhone 6s 1080p120iPhone 6s Plus 1080p120

In 720p120, the iPad Pro is clearly worse than the iPhone 6s and 6s Plus just by virtue of not supporting 1080p here. That's not exactly surprising, but as a result the quality looks to be roughly comparable to the iPhone 6. Given that both are using H.264 high profile at 30 Mbps it’s not exactly a surprise though. The Pixel C and Nexus 9 are both unable to participate in this test at all as they don’t support slow motion video, which might be an ISP limitation of some sort as we’ve seen Nexus devices on the smartphone side with support for slow motion video.

Overall, camera performance on the iPad Pro is probably as good as it gets for tablets, but it's obviously not competitive with the best smartphones. No one should really be surprised that this is the case though, as tablets are basically cameras of last resort, while smartphones are often primary cameras now.

Misc.

On the WiFi side unfortunately I have reason to doubt the validity of our current testing methodology, especially on iOS. As a result for this review we won’t be running any particular benchmarks for the iPad Pro but I never saw any particular issues with WiFi performance on the iPad Pro, which uses Broadcom’s BCM4355 WiFi/BT combo chipsets.

I also don’t have any particular equipment to really test speaker quality to its full extent, but subjectively the speakers are some of the best I’ve ever experienced on a mobile device in terms of sheer volume and frequency response. The speaker amps are shared with the iPad Air 2, which is Maxim Integrated’s MAX98721 IC. The audio codec/DAC is Cirrus Logic’s CS42L81, which isn’t entirely unsurprising given how most every Apple mobile device seems to use a Cirrus Logic codec of some sort.

I also found a number of interesting design wins, which include TI’s BQ27540 for the battery fuel gauge, and an MCU related to the Orion dock that seems to handle accessories like the Smart Keyboard. This MCU is connected over i2c, with some suggestion that this connector can act as a USB port, but I haven’t been able to figure out much else about this system.

Final Words

Overall, the iPad Pro has proven to be a very different experience for me than previous iPads. The design is definitely familiar, with the same industrial design and general feel as previous iPads scaled up to a 12.9” form factor. However, the change in size is something that feels like it should have been done from the start. Of course, there are people that will carry tablets in cargo pockets that want something closer to a 7” display and people that carry tablets in purses that want a ~10” display, but if you’re like me and the only way you can realistically carry a tablet is in a backpack then the 12.9” size makes far more sense.

It’s also noteworthy that despite this increased size I didn’t really notice that it had gotten significantly harder to handle in the hands than an iPad Air 2. This is likely helped by avoiding placing heavy batteries at the edges of the tablet, which reduces the moment of inertia and associated hand or arm strain from holding the tablet for hours on end. This is especially important when considering the Apple Pencil which makes it pretty natural to hold the tablet with one hand and draw with the other for hours on end.

On the SoC side, we’re finally seeing a major player in ARM SoCs directly competing with Intel on their home ground of sorts, and the results are at least somewhat shocking. Despite a handicap on process node, the CPU of the A9X isn’t all that far off from Skylake Core M. And while A9X can't go toe-to-toe, Apple is for the first time capable of reaching Intel's level for some workloads. Otherwise on the GPU side, Apple arguably bests Intel. While iOS vs. Windows doesn't lend itself to as precise comparisons as we'd like due to some fundamental architectural differences, for a developer writing a GPU-accelerated application tailored for the platform the A9X’s 12 Cluster Series7XT GPU is capable of doing more than the Core M’s Intel HD 515.

Ultimately Apple's Twister CPU core is now the “new normal” for Apple devices, so I’m not nearly as blown away as I was with the iPhone 6s, but I really do have to emphasize that this SoC is incredibly fast. Currently, it has no real competition in the ARM SoC space, and I suspect it won’t for quite some time even in light of new SoCs on the horizon like the Exynos 8890 and Snapdragon 820, as the SoC is tailored for tablet use rather than a smartphone SoC with more thermal headroom. When combined with the Apple SSD present in this device, it’s hard to complain about performance for the most part.

This strong showing in SoC performance, combined with a noticeable amount of work on the display results in a relatively impressive level of battery life. While it isn’t really better than the iPad Air 2 here, the sheer efficiency of the hardware in the iPad Pro means that the battery is smaller on a relative basis despite the large difference in display size. It’s easy to fixate on battery size as the sole determinant of battery life, but that ignores half the equation. The one notable area where efficiency isn’t as good as one might hope is LTE battery life, but I suspect that the impact here isn’t going to be as noticeable as it is with a smartphone as even with our LTE variant I spent most of my time using WiFi to get work done.

From an internal hardware perspective the one real issue here is the rate at which the iPad Pro charges, which is starting to approach unacceptable levels. Future iterations of iPad Pro really need to ship with a much more powerful charger. Even 4 hours to charge is pretty excessive compared to the 3 hours or so that it takes most laptops to charge or the 2 hours that it takes for a phone to charge.

On the display side, Apple continues to ship some of the best displays I’ve seen in the industry. The iPad Pro is no exception, with a relatively bright panel combined with an incredibly good anti-reflective coating to basically eliminate the disadvantages that come with glossy displays. The move to a new display technology also makes for some truly impressive contrast figures for an LCD, although it’s not a competitor to OLED if you only focus on contrast. As an aside, I suspect microLED or OLED is going to have to take the place of traditional LCDs at some point, as OLED is probably going to be unambiguously superior to even the best LCD by the end of this year if the trajectory of improvement continues.

But LCD or not, the iPad Pro’s display also has incredibly good color calibration. Apple does tend to prefer slightly blue white balance, but I suspect this is mostly a trade-off between color accuracy and power efficiency. For color-critical work in areas like medical and creative industries I suspect that the iPad Pro is sufficient due to its relatively low color shift with changes in viewing angles. It’s also interesting to see that there is clearly evidence of Apple’s custom DisplayPort timing controller (TCON) within the system files, but we basically have to take Apple at their word that this TCON is dynamically switching between 60 and 30 Hz refresh rates as I really couldn’t tell that this was happening in practice, or within system files.

While the basics are critical, the iPad Pro earns its “Pro” moniker on the basis of its accessories, the Apple Pencil and Smart Keyboard. The Apple Pencil is unquestionably the best stylus I’ve ever used in any mobile device. I would argue that the Apple Pencil combined with the iPad Pro is probably the single greatest threat to Wacom’s dominance in the professional market today. We can spend all day arguing about how Apple Pencil has no buttons and has an odd charging method, but for $900 USD you can either buy a Wacom Cintiq 13HD Touch or an iPad Pro with Apple Pencil. If the right apps are available on the iPad Pro, it’s pretty much indisputable that the iPad Pro is going to be a better, more elegant solution for getting stylus-related work done.

Outside of creative work, the Apple Pencil is shockingly good as a pencil/pen and paper replacement. Even with the default Notes app I felt like the iPad Pro is far and away superior to carrying around a folder, notebook paper, pencils, pens, erasers, straight edges, and textbooks. I’ve always been looking for a tablet that could be seriously used for academic work, and the iPad Pro is pretty much what I’ve always been looking for. The Surface Pro 4 comes close to be sure, but I would argue that it really isn’t a proper tablet by virtue of how dependent it is on trackpad input. The stylus also just not as well-implemented as the iPad Pro, which is evident as soon as you try to do perfectly straight diagonal lines. In addition to education contexts, I wouldn’t be surprised to see Apple Pencil take off in areas like point of sale registers. While 3D Touch is great, the Apple Pencil managed to surprise me even more. However, the applications of Apple Pencil are somewhat limited to these specific cases compared to the more universal applications of 3D Touch.

The Smart Keyboard by comparison is a bit of a letdown. While I like using the keyboard a lot when I can set it up on a table or something and do nothing but type out paragraph after paragraph, the trouble is that as soon as some other UI interaction is needed the user experience kind of falls apart. Both setting up and taking down the keyboard takes some time, and doing the motions/origami necessary to do this is not something that can be done carelessly as the Smart Keyboard can and will fall apart/behave unpredictably if you don’t put it together properly. In order to really hit it out of the park, the Smart Keyboard needs to be more stable in the lap, have at least one more useful angle, and be much faster to set up/take down. In essence, the hope is to be able to rival a touch keyboard for bring-up/take-down, but introduce the ability to touch type at speeds that touch keyboards realistically cannot hope to rival. I don’t really think it’s reasonable to argue that the iPad Pro with the keyboard set up is an ideal experience for UI navigation, as using the touch screen is about as ergonomic as a touch screen laptop and using the keyboard for navigation only feels an awful lot like using a command line interface.

In fairness to Apple though, the Smart Keyboard is arguably the right direction for tablets to take. We can talk about how the Surface Pro implementation is better, but I’m still not a big fan of using a trackpad on a “tablet,” and pecking at a display with my finger is arguably even worse. The kickstand also has a lot of issues with lap stability as well, although it does resolve some of the concerns with getting the right angle for proper visibility of the display. The problem of text input on a “pro” tablet is one that needs new solutions, and other than the iPad Pro and Pixel C I honestly haven’t seen anything that comes close to getting in the right direction.

On the software side of things, the iPad Pro continues to be one of the few (if not only) tablets that has an OS and UI that is properly designed for a mobile tablet. Microsoft is doing an admirable effort here with Windows 10, but the sheer difficulties that I have with something as simple as high DPI scaling in Windows is just unacceptable for a tablet. It’s also difficult to deal with the sheer number of legacy applications out there, which really complicates control schemes. I found the vast majority of the time I ended up having to use a stylus or trackpad for simple UI interactions because the touch targets were just too small otherwise. Android has some pretty severe issues with making a tablet UI that is more than just a scaled-up phone UI, which leaves the iPad Pro as more or less the only game in town. There are some issues that stem from the lack of ability for apps to really interface with each other and the difficulty of abstracting away the file system, but for the most part I found iOS to be quite good for getting work done.

However, iOS is not a perfect tablet OS. One real problem here is that the multi-window UI isn’t quite as good as it needs to be. While the current list of apps that fully support this functionality isn’t unmanageable, as time goes on I suspect it will get to be rather annoying to scroll through a long list of apps. There’s also the issue of performance. While there was a time when iOS was just incredibly smooth all the time, I’m starting to notice a trend of apps and general UI tasks that show rather concerning levels of frame drops. I’m not really sure exactly when this happened, but something as simple as scrolling through the Notes app shows frame drops on par with scrolling through Google’s Play Store app. This is definitely an area where Apple should focus on improving, as performance problems shouldn't be a concern with a tablet that's as powerful as the iPad Pro.

While the camera is arguably quite low on the list of priorities for a tablet, Apple manages to deliver one of the best cameras in a tablet today. I honestly wouldn’t advise using it as an actual camera, but as a last resort it works quite well. The speakers are also hugely impressive for multimedia use, and probably beat everything else I’ve ever tried on a mobile device, although this is based upon subjective observation. I found that watching YouTube and movies on this tablet is great when paired with the speakers. People that only use headphones for audio might find this feature pointless, but if you’re sitting in bed or in your room watching a movie it’s definitely convenient to not have to put in headphones while getting acceptable audio quality.

Overall, the iPad Pro is an incredibly good tablet. I’ve always liked the idea of a tablet, but for the most part I’ve been deeply dissatisfied with the implementations of tablets. With the iPad Air 2 review I really emphasized how a proper keyboard and a good stylus would really make the user experience much more compelling, and with the iPad Pro we’re finally starting to see movement towards the tablet that I’ve always wanted. The iPad Pro is arguably the first tablet that I personally want to even consider buying. It isn’t perfect by any means, and there is still a lot of work to be done - seemingly fitting for a first-generation Apple device - but for the first time in a long time it feels like the broader tablet market is advancing once again. If you want a proper tablet that can replace pencil and paper with a keyboard for extended typing sessions, I have no problem recommending the iPad Pro. If you're hoping for a laptop that can also double as a tablet, I suspect that the Surface Pro 4 will remain the right choice for you.