3D APIs prehistory
OpenGl is an example on one of the first 3D APIs. OpenGL has played an important role since the beginning of 1992. It’s an open standard where open means that it’s free and free to implement and use. One of the main goals for the standard is platform dependency. The specification and its development was originally controlled by a group called OpenGL Architecture Review Board that was a mix of Apple, Intel and Microsoft. Today that role has been taken over by the Kronos Group, and the members has for years been coming and going, but the essence is that it’s the same. It’s still a standard that is run by a commetee.
Microsoft choose early on to leave the group and focus on their own API Direct3D (D3D).
3dfx launched in 1996 their own Voodoo graphic card and their own proprietary API 3D slider which was the beginning of a 3D revolution. The coming years offered a line of 3D graphic cards and corresponding APIs. A historical whims was that one of these APIs was named MeTaL.
Microsoft dominance in games
Towards the ending of the 90s there were really only two players back. OpenGL, the open standard, that focused on platform dependency and D3D, the Microsoft run standard, which only supported Windows.
- It’s obvious to declare D3D as the winner solely because Windows was and is the dominant desktop platform, and because Windows developers typically choses D3D instead of OpenGL.
- The conclusion is that they both found their own marked, and where D3D primarily is used for games OpenGL found its market in the production-applications.
After the millennium new possibilities opened for OpenGL in connection with the rise in handheld devices. Since these devices only had limited power it meant that OpenGL in its current form was not suitable. This created OpenGL for Embedded Systems (GLES). GLES is a subset of desktop OpenGL and has therefore much in common with each other, but they are two separate APIs and GLES can typically not be used directly on desktop.
When iOS and later Android smartphones started to show up it was with GLES in a central role. After that a couple of years past where GLES was the dominant platform. This leads us to the latest development.
Figur: Metal for Apple iOS, Vulkan for Android and OpenGL
AMD chose to present a new initiativ in 2013 called Mantle. Mantle was a consequence of years of a growing need to do away with existing 3D APIs. They where in many ways no longer contemporary. Multi-core CPUs had long been the norm but the existing 3D developers had to little control over for example memory controle and validation. Mantle was the first in a line of so-called low-level 3D APIs. With low-level it’s meant that the API is a minimal abstraction over hardware and leaves much more responsibility to the developer. Mantle was never officially published but was instead donated to the Khronos Group and is the starting point for what was the beginning for Vulkan, which was published in 2016. Microsoft launched their own, Direct32 12 in mid 2015 which is a low-level API for Windows 10, Xbox One and Windows Phone 10.
More surprising was it that Apple out of the blue presented Metal in 2014. To begin with it only supported iOS, but since OS X EL Capitan it’s also supported on desktop. Apple has more or less made it clear that the future on their platform is called Metal. Apple has always wanted to have full control of both software and hardware and in that optic it makes sense that they are slowly fading out the committee run OpenGL/GLES. Maybe not officially but in praksis by all the versions that no longer support OpenGL/GLES. Apple added OpenGL 4.1 support for OS X 10.9 in 2013 which is more that 3 years since the specification was published. For reference was the 4.4 latest version at the time and in 2014 came version 4.5. The rumour has it that it succeeded Apple to make an easy accessible but also effective API.
Vulkan is in many ways what Longs Peak (codename for OpenGL 3.0) newer was. Vulcan has presented a revolution but not yet an evolution. Vulkan takes away the devision of what was known from GL/GLES. Now there’s only a collected API for desktop and mobil. Vulkan is likewise in reality not a 3D API, but a core where 3D is an expansion. This means that Vulkan also support Compute functionality (this goes for D3D 12 and Metal), that previously demanded a not always direct trivial integration with OpenCL.
There are still comparisons between OpenGL, for example, the development of the standard is still run by the Khronos Groups members, and platform dependency is still the focus of attention. There has to be both victories and loss. Where openGL is supported by the three largest desktop platforms and GLES on both iOS and Android, Vulkan is a streamlined API that supports both desktop and mobil. Unfortunately support for the Apple platforms has been lost.
It’s important not to let yourself get blinded by Vulkans potential. APIs are radically different than for example OpenGL. OpenGl has over the years become more complex in line with more added possibilities for developers, but Vulkan turned it up a level more. The price for higher performance is determined by more responsibility. You are in other words not guided as previously and sources for mistakes are many.
Android is the widest platform. Given that you will not find support for D3D 12 or for Metal, but its the only mobile platform that supports every version of OpenGL ES. iOS supports up to version 3.0. Android has been the driving force of OpenGL ES standard, which is supported by the fact that the latest version 3.2 was called Android Extension Pack.
Depending on what kind of app you are developing, 3D can either fill a little, or be the source for great frustration. If your app has a focus on 3D then the number from 7th of November 2016 is going to be boring to read. They show that 43.1% of Android unites are supported by GLES 2.0 while the number of unites that supports 3.0 is located on the 42.2%. Unites that supports 3.1 is located on 14.7%. These are in theory Vulkan compatible but in practice it depends on whether the unite’s graphic driver gets updated. There are no official numbers about the percentage that supports Vulkan, but they are with out a doubt lower that the 14.7%. The numbers shows clearly that they’ll lose a lot of members if they go higher that 2.0.
In spite of the dark numbers it’s largely depends on what the app is going to solve. Developers often dont have a direct need for a user defined 2D or 3D graphic and can therefore more or less be ignored. In other cases where the need is fore 2D, Android offers 2D-specialised views and classes like for example SurfaceView and Canvas. If you are in demand of user defined 3D graphic, Android GLSurfaceViwe and GLSurfaceView.Renderer where as the prefix Gl indicates Javabinding to OpenGL ES functionality.
Androids Native Development Kit
There is an extra alternative to use GLES in Android and that is through Android Native Development Kit (NDK) where you implement your own 3D logic in C/C++ instead of java. It’s possible to gain some performance by implementing C/C++. In other cases it can make sense if you already have C/C++ GLES code or if there is a need for reusing code on other platforms. As a general rule it’s recommended that a native solution is not implemented without careful thought by thinking that one platform is better than the other. That makes the complexity of the app more complex by mixing Java and a C/C++ codebase.
This issue is not exclude if Vulkan is chosen since it’s only supported through NDK and Google has indicated that a javabinding is not to be expected since a lot of the advantages by a Vulkan is then lost (read more here)
The latest years has shown a tendency towards conversion towards own platform. D3D 12 is only supported by Microsofts own platform. App is betting on Metal for iOS and macOS. That leaves Android as the only one that still bets on the open platforms, GLES and Vulkan. In other words it’s become a larger task to support all the popular platforms. For smaller companies the tast seams almost impossible if they are to handle it by them selves. That’s way many are choosing to let third parties handle the platform dependency code like for example Unity.
As an Android developer its more interesting to follow Vulkan. There has been a lot of hype and for many it’s been surprising that it’s not a silver bullet for solving low frame rate, but that it takes a new kind of thinking and maybe even to leave once own comfort zone since it’s not in the cards that Google will expose Vulkan functionality through Javabindings. Vulkan version 1.0 came out under a year ago, so it’s still early and theres only a few unites that supports it. There is therefore nothing that looks as if GLES is on the way out of the Android ecosystem for now.
There is a new exciting player in the form of Vulkan, but with the slowly spread of GLES 2.0+ and Vulkans increased complexity, GLES will still have a relevance in the coming years. That thread isimmediately if Google is to follow in Apples tracks and make their own API, that eventually will be based on Vulkan.
By Steen Rasmussen
Senior Android developer at Touchlogic