Fragmentation threatens market expansion
Google representatives recently spoke with several SoC builders about developing chips based on Google’s designs. It is part of a push by the company to bring uniformity to what they fear is a fragmented universe of Android phones.
What would this mean for GPU vendors? Avoiding fragmentation in the Android platform is good for all—but Google prescribing exact silicon designs could further commoditize the silicon market, eventually removing any incentive for hardware vendors to invest in the platform at all. What to do?
One way perhaps is not to prescribe detailed designs but to instead put more attention into API standards. A well-designed API defines strict conformance to avoid fragmentation, but does not pre-scribe implementation details—leaving the opportunity open for silicon vendors to differentiate and compete. The Khronos Group has long understood the necessity of defining APIs for interoperability in a way that encourages, rather than prohibits competition.
When Khronos officially launched OpenGL ES in July 2003, the goal was to provide a royalty-free open API that would stabilize the interface between content developers and chip builders, encouraging market growth for both content and devices. OpenGL ES succeeded and can be rightfully credited with helping to power the rapid rise of the smartphone and tablet markets.
However, the quest for differentiation by hardware manufacturers never ends, and so special features and extensions would get added to the SoCs and their GPUs. For the most part, Khronos handled those developments by embracing them as standardized extensions and eventually adding them to a next-generation core spec. Overall, it’s been a process that has worked, giving hardware vendors freedom for differentiation, while keep API fragmentation in acceptable bounds.
But now the GPU API landscape is undergoing a radical change—with a new generation of APIs appearing from Microsoft (DX12), Apple (Metal), and Khronos (Vulkan) carrying the promise of more explicit GPU control for enhanced performance and predictability.
In particular, Apple with Metal (proprietary 3D API), Swift (proprietary programming language), and a host of proprietary libraries are attempting to become programming islands by increasingly prohibiting (unlike Microsoft’s Windows) open standards from their devices—locking content to their platform only.
Will the other platforms follow suit to create a perfectly fragmented API world, where the content developers and silicon vendors pay the cost of increased porting costs and developing multiple driver stacks? It’s a shame for developers—Apple has put them into a bifurcated world if they want to use the new-generation APIs—no one new-generation API will cover all platforms. Will Apple come back to open standards? Perhaps if they lose more content than they gain through being isolated—time will tell.
Google is smartly responding by embracing open standards so they can leverage the investment of a whole industry—e.g., adopting Vulkan for GPU compute/graphics to compete with Apple Metal.
Just like Microsoft Windows, Android’s biggest strength and challenge is to enable a diversity of hardware vendors under an ecosystem big tent. It is a tremendous engine for innovation and investment— but the constant challenge is fragmentation.
So it’s easy to understand Google’s urge to guide hardware design, and Vulkan will be key to standardize native access to GPUs as part of this puzzle. Google is also talking about camera hard-ware—which has been a horribly fragmented area, with the cost and complexity of integrating a new camera sensor and ISP often holding back innovation and limiting app portability. Khronos has a nascent camera standard (OpenKCam), but it has proven hard to get off the ground while Google is working on proprietary APIs—so it’s a delicate balancing act Google will have to play.
Back in GPU land, OpenGL ES has eliminated a lot of GPU fragmentation across Android and iOS for a long time—but many engine developers are now demanding the new-generation APIs Vulkan/DX12/Metal.
In practice, OpenGL ES will still be a force for good for years to come; it is continuing to evolve with OpenGL ES 3.2 shipping in March 2015. Google has stated they will ship OpenGL ES in parallel with Vulkan. Apple has not removed ES from their platform yet (and Apple tvOS included it). If they don’t remove it, OpenGL ES will continue to be the cross-platform GPU API for most developers that don’t need the new-generation APIs quite yet.
Will Google be able to continue help create and leverage effective open standards APIs for other parts of mobile SoCs, such as CPUs and cameras, that reduce fragmentation while still enabling healthy vendor competition as OpenGL ES and Vulkan have for the GPU? For the sake of hardware and software developers everywhere, let’s hope so.