Original Link: http://www.anandtech.com/show/4658/its-not-qualcomms-fault-dispelling-touchpad-myths
It's Not Qualcomm's Fault: Dispelling TouchPad Mythsby Anand Lal Shimpi & Brian Klug on August 19, 2011 6:40 PM EST
There's a whole lot of misinformation on the web right now about reasons why HP had troubles with the TouchPad and eventually had to abandon the entire webOS hardware division. We'd moved on internally after yesterday's news but a bunch of stuff that popped up online today prompted a quick discussion about the realities of webOS hardware.
It's Not Qualcomm's Fault
Someone somewhere started this idea that by using Qualcomm hardware the TouchPad and presumably Veer/Pre 3 were handicapped. The theory is that by using Qualcomm hardware HP somehow limited performance of these devices and made it very difficult to run on devices that used other, non-Qualcomm SoCs.
Time for a reality check.
Palm's webOS launched on TI's OMAP 3. The original Palm Pre ran on an OMAP 3430. In fact, I did a quick head to head between it and the iPhone 3GS when it came out given the similar specs of the 3430 and Apple's 3rd generation SoC.
The Palm Pixi, on the other hand, used a Qualcomm MSM7x27 SoC. At the same time, the Palm Pre Plus was available with the same OMAP 3430 as the original Pre. Here we have two different SoCs which themselves implement different versions of the ARM instruction set (the MSM7x27 runs ARMv6, OMAP 3430 runs ARMv7), and yet it was possible to port the current version of webOS between two different SoCs from different vendors running different ARM instruction versions entirely.
Morover, webOS 2.0 is fundamentally the same beast at an OS level as webOS 1.x. The Pre Plus and original Pre can run webOS 2.x just fine (with appropriately changed radio firmware), an OS originally intended for the OMAP 3630 in the Pre 2 and the HP Veer's MSM7230. Porting between different SoCs thus isn't entirely impossible - already we're up to webOS 1.x and 2.x running on 4 different SoCs. It's reasonable to say that porting is actually relatively easy.
In fact, while doing the HP Veer review and poking around inside webOS 2.1.2, we found numerous references and plugins which were definite remnants of OMAP3 compatibility. This isn't a surprise at all considering that the Pre 2 likewise runs webOS 2.1.0.
It's not flip-a-switch trivial to port between SoCs, but it's not shoe-eating impossible, either. Apple, NVIDIA, TI and Qualcomm all implement the same ARMv7 instruction set in their latest SoCs (with the exception, again, of the Pixi's MSM7x27 which used ARMv6), and thus code compiled for one processor should run just fine on another. There are differences in terms of power management and what other instruction set extensions are supported (e.g. ARM's NEON SIMD extension, or thumb, vfpv3, and others) but these are minor in the big scheme of things. They require development time, but presumably the webOS team has (or is it had, now?) developers on staff whose responsibilities were to smooth over these differences.
Respective Extensions from cat /proc/cpuinfo:
MSM8x60/APQ8060:Processor : ARMv7 Processor rev 2 (v7l)Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3OMAP3x30:Processor : ARMv7 Processor rev 2 (v7l)Features : swp half thumb fastmult vfp edsp neon vfpv3MSM7x30:Processor : ARMv7 Processor rev 1 (v7l)Features : swp half thumb fastmult vfp edsp thumbee neonMSM7x27:Processor : ARMv6-compatible processor rev 5 (v6l)Features : swp half thumb fastmult vfp edsp java
One of the bigger issues in porting between these SoCs has to do with graphics drivers. While all of the aforementioned companies implement the same ARM instruction set, they all use very different GPUs. Each GPU requires its own driver, no different than on an notebook or a desktop. In the Windows world it's like driver heaven, every major GPU has a driver available for every major version of Windows. In the mobile space it's a bit more complicated.
Because there's an Adreno 220 driver for Android doesn't mean that one exists for iOS or webOS. To a certain extent, each OS needs its own driver. Granted there can be a lot of code reuse thanks to similar standards existing across the OSes (OpenGL ES 2.0 for example is on all three OSes) but here's another area where development time is required.
There are other differences as well between SoCs. Differences such as what video encoders the OS will use for camera input to encode both JPEG and MPEG video. What decoders onboard the SoC to use for video playback or flash video acceleration. Where and how big the SDRAM is. What interfaces (I2C, SPI, GPIO and USB) are to be used for accelerometer, ambient light, gyro, pressure, or compass sensors. Which of those I/O ports are used for controllers for the touch panel, backlight, LED, vibrate and WLAN. All of these are considerations that make moving an OS between not just SoCs but hardware platforms, something that initially seems daunting but really amounts to pointing things in the right direction and including the right kernel drivers. Thankfully since webOS is linux based, the kernel should take care of a huge percentage of that difficulty and largely make any SoC that Android runs on a potential host for webOS.
In the end, while it does require work to port webOS to various SoCs it has not only been done in webOS history but it's a small part of the work required to bring a new tablet or phone to market. If this were an insurmountable task then we wouldn't see Android working on every single major SoC released.
It's Really Not Qualcomm's Fault
We've established that webOS has been and could be ported to different SoCs from different vendors – there's nothing tying it irrevocably to Qualcomm. The next is a discussion of the performance delta that existed because of differing hardware between tablet vendors. The Next Web wrote a story today claiming that webOS could run over 2x as fast on an iPad 2 than on an HP TouchPad. The claim gets even more interesting:
"With a focus on web technologies, webOS could be deployed in the iPad’s Mobile Safari browser as a web-app; this produced similar results, with it running many times faster in the browser than it did on the TouchPad."
Anyhow, the TouchPad uses Qualcomm's Snapdragon S3 APQ8060. It has two Scorpion cores running at 1.2GHz, a shared 512KB L2 cache and a dual-channel memory controller. In the TouchPad there's only a single 1GB DRAM on board. It's unclear if there are two DRAM die on that package or not, so whether or not the SoC is actually given full access to 2 x 32-bit LPDDR2 devices is unclear. The CPU cores are in-order and feature a pipelined FPU and NEON unit. On the GPU side the APQ8060 uses Qualcomm's Adreno 220.
If this hardware sounds familiar to you it's because it's the modem-less version of the MSM8x60, the same SoC used in the HTC Sensation and the EVO 3D.
The iPad 2 uses Apple's A5 SoC manufactured by Samsung. It has two ARM Cortex A9 cores, a 1MB shared L2 cache and a dual-channel memory controller. The A5 in the iPad 2 comes in a PoP (Package-on-Package) configuration with the DRAM stacked on the SoC die. Although it's physically unclear whether both channels are populated, the Samsung DRAM part number on the A5 indicates a PoP stack with two DRAM devices. In other words, the A5 is running in dual-channel mode. The CPU cores are out-of-order, feature a pipelined FPU and NEON unit. Imagination Technologies supplies the PowerVR SGX 543MP2 GPU in the A5.
From a CPU standpoint, Apple has a performance advantage at the same clock speed, but Qualcomm runs its cores at a higher clock. NVIDIA claimed that the move to an out-of-order architecture in the A9 was good for a 20% increase in IPC. Qualcomm has a 20% clock speed advantage. In most situations I think it's safe to say that the A5 and the APQ8060 have equally performing CPUs.
Apple does potentially have a memory bandwidth advantage as it's unclear the memory configuration of the TouchPad. I did wonder if this might be a reason why UI transitions were so slow on the TouchPad. In order to deliver a smooth UI you need good GPU acceleration built into your OS and you need sufficient memory bandwidth for the screen. At 1024 x 768 you need 180MB/s of memory bandwidth to render a UI at 60 fps. That's assuming no overdraw or multi-pass blending effects. With only a single LPDDR2-667 channel there's only 2.7GB/s of theoretical memory bandwidth. In practice you generally get 80% of peak theoretical memory bandwidth, that takes us down to 2.1GB/s. If we assume webOS was really inefficient in drawing its UI and needed 7x the bandwidth per frame, that still leaves us with 840MB/s of bandwidth available for the rest of the SoC. Assuming the CPU cores aren't doing anything, that's enough to provide a smooth, 60 fps UI. Start taxing those CPU cores and their bandwidth demands could go up to a few hundred MB/s, perhaps even more. Let's not even mention what happens if the GPU starts cranking away.
Now if we assume that webOS is super efficient, then even a single LPDDR2 channel is more than enough to deliver a high speed UI. In my calculations above I assumed a 7x increase in memory bandwidth requirements per frame. If we knock that down to 4x we nearly double the amount of memory bandwidth available to the rest of the SoC.
My point here is that the Qualcomm hardware is technically fast enough to deliver a smooth UI in webOS. The problem wasn't the hardware.
As far as CPU performance goes, here's a graph comparing the Tegra 2 based Galaxy Tab 10.1 to the A5 based iPad 2 in Sunspider 0.9:
Granted this test measures the entire hardware and software stack (browser, OS) and does show a ~2x performance delta between the TouchPad and iPad 2, but it shows that it's physically possible to build a tablet that has performance similar to the iPad 2. Furthermore, we've already shown that NVIDIA's Tegra 2 performs similarly to Qualcomm's dual-core SoC in other situations. Completing the circle it's safe to assume that at least from a CPU standpoint, Qualcomm's APQ8060 wasn't the factor holding back the TouchPad, it was software.
The only area where the iPad 2 could conceivably be 2x the speed of the TouchPad due to SoC hardware alone is in GPU performance. However the claims above say the performance advantage was demonstrated in a browser window and not in a cross-platform OpenGL ES 2.0 game.
These days Qualcomm's high end dual-core SoC is comparable to TI's and NVIDIA's. Each platform has its advantages but I find it very difficult to believe that Qualcomm was somehow responsible for the poor performance of the TouchPad.
webOS Needed Work
From the very beginning, webOS needed work in the optimization department. The hardware wasn't at fault, it was the software that always needed tuning, and as we saw with the Pre Plus even throwing more RAM at the problem didn't speed things up enough. We mentioned a number of places where webOS 2.0 still needed work to improve performance and smoothness in the Veer review. First among those really were the criminally long boot times:
"Unfortunately loading times on the Veer are still incredibly long due to some mismanagement of the linux boot process. Unfortunately it appears that WebOS increases the sleep time that apps send to the caller during the boot process from an already crazy 60 seconds to 120 seconds. There's discussion of this on WebOS Internals, but the situation is even worse now, at 120 seconds."
What Palm managed to develop was an excellent UI and front end to an OS, but there's little doubt that the underlying Linux code needed (and still needs) work. Simple tricks like disabling logging and implementing the boot process properly would result in noticeable performance gains. There's little dobut that other similar simple things could dramatically improve performance.
The fact of the matter is that Palm needed a lot of development time to turn webOS into a mature product. The HP of today is trying to turn itself into a fully focused enterprise company and as a result, webOS wasn't going to get the support it needed. An internal source at HP told me that the sales targets for the TouchPad were between the best selling Honeycomb tablets and the iPad. When that didn't happen, HP saw no reason to continue down the webOS hardware path.
As an enterprise company the move makes sense for HP and its shareholders. As consumers, we're disappointed. But the blame doesn't fall on Qualcomm or any chip vendor in the TouchPad, just on HP itself. The TouchPad needed more work, and webOS as a whole needs more work. You can either scale a project out by taking more time to get it done, or you can scale its width by committing more resources to it. The latter (and more efficient development) is what Palm has needed since day one, what HP promised to bring to it, and sadly exactly what it ultimately failed to receive at HP.