“Game” and “Configuration” are two words that are heard together almost too frequently together. Whenever an intriguing new game or the next big instalment of a popular game is announced, the first thing we check is the prescribed minimum system requirements. Apart from the basic details like RAM, Graphics memory, Operating System required, we don’t look into the requirements too deeply.
When it comes to Graphics APIs, most of us have only heard of DirectX and Metal for Mac, that too not as Graphics APIs, but as a piece of software that needs to be present for a certain game to run on our Windows PC or Mac. Chances are that most of us don’t really know their purpose and how the new low-level Vulkan API is going to affect them.
The roadmap to the present
Back in the days, when computer games used to be mind blowing due to their mere existence, games were simple enough to run directly off hardware. If you see the game as a piece of code, this code ran directly on the underlying hardware like any other piece of code and required no intermediary. There was little or no reusability between games. The design approach for games was Bottom-Up to make optimal use of the hardware. Even though the 1980s saw the presence of some generic game development tools like ASCII’s RPG maker, Pinball Construction Set etc, most game developers who developed for the arcades used in house game engines to create games for each type of arcade device.
Over time, the underlying hardware gradually got more powerful and consequently complicated. Directly interfacing with the hardware was either no longer feasible or required a herculean amount of effort for any kind of software developers. The concept of device drivers was introduced as a layer between the hardware and the software application. This was also necessary to make the software function on the variety of devices emerging into the market. A Graphics API (Application Program Interface) is also a specialised driver that is required for communication of standard functions and instructions used by the application and supported by the driver, which in turn acts as a translator for these instructions to be encoded as commands to the hardware.
During the mid-1990s, Id Software’s DOOM and Quake became so popular that other developers preferred licensing core portions of the game and overlay those with their own level designs, characters, gameplay mechanisms, graphics i.e. the actual “content” of the game. Eventually, games began to be designed with this approach in mind, leading to Epic Games’ Unreal Engine and other such game engines. A Game Engine behaves as a higher level library that implements abstract concepts like entities, material, camera, lights using the capabilities of the lower Graphics API, like mesh, texture, shaders etc.
At present, both Games and Game Engines are incredibly complex and expensive to make. Most Game development studios have stopped focussing on developing game engine technology and prefer to use existing options in the market such as Unity3D and Unreal Engine. Consequently, graphics drivers have also become substantially complicated. As a gamer, it might escape one’s attention but one look at the size of the installer tells us the amount of code that goes into something that does not directly contain any of the actual graphics or media assets. That is because each driver has to implement a lot of APIs (DirectX versions, OpenGL versions etc) and also has to be backward compatible. This complexity and enforced compatibility often leads to unnecessary overhead and unwanted bugs.
The above diagram shows how the interaction between the hardware and the application has evolved to the present
The story of the predecessors
The history of Graphics APIs began much before the 90s but one of the main boosts was received during that era. PHIGS, the standard being used by the industry for Graphics development, was gradually replaced by the IRIS GL API by Silicon Graphics, mainly due to ease of use and immediate mode rendering, which was more suitable for rendering more complex graphics compared to the open standard that PHIGS was.
But due to competition from Sun Microsystems, IBM and Hewlett-Packard’s own 3D hardware being brought into the market with extensions made using the PHIGS open standard, SGI began to lose market share. In an effort to regain the same, they turned their own standard open source and renamed it to OpenGL.
OpenGL was more than a mere rebranding. It overcame drawbacks in IRIS GL that prevented an application from implementing and using a feature that was intrinsically unsupported by the underlying hardware. The control of OpenGL was handed over to OpenGL Architecture Review Board, which was an industry consortium of companies like Apple, IBM, Intel etc.
In the mid-90s, Microsoft had released the first version of its own proprietary API package as Windows Games SDK which they later named DirectX. Even though initial adoption of DirectX was slow with programmers, publicity efforts along with thorough testing and compatibility measures from Microsoft gradually grew its popularity within the Windows Platform. Prior to DirectX, Microsoft had included OpenGL support for WindowsNT targetting engineering and CAD applications and the Direct3D API in DirectX was originally intended to be a low-level support for usage like gaming. Over time, as graphics grew more complicated, OpenGL also included multimedia support and programmers got the option to choose between the open-source OpenGL and Microsoft-only DirectX. Incidentally, DirectX did support OpenGL. For example, if a developer chose to use the OpenGL 3D graphics API, other DirectX API’s were combined with it to be used for games because there were some features of DirectX that OpenGL did not provide, like joystick support.
For the console side of Microsoft’s ventures, DirectX formed the basis for the entire Xbox range’s API. The entire API was developed by Microsoft in conjunction with Nvidia which built the hardware for the Xbox. In fact, the Xbox was originally named DirectXbox, but later renamed for commercial purposes.
On one side, as Microsoft has been gunning their DirectX efforts, the control of the OpenGL was passed to another industry consortium called the Khronos group in July 2006. The Khronos group consists of a much larger scale of companies like AMD, Apple, Google, Mozilla, IBM, Samsung, RedHat, Microsoft, Oculus, Panasonic, Nintendo, Pixar, Lucasfilm, Amazon, Valve, Unity, Nokia, Nvidia (We are sure you get the drift!). Further development of OpenGL was handled by the Khronos Group.
The Galaxy S7 supports Vulkan API
Metal for iPhones and other Apple devices debuted in iOS8 and aimed to bring support and benefits of similar APIs in other platforms to the Apple Ecosystem. Metal’s features differentiated itself from OpenGL by mainly reducing the CPU overhead and explicit synchronization between CPU and GPU, which basically reduced the number of tasks to be done by the CPU leaving it free to take up additional load.
AMD’s proprietary solution, the Mantle API was introduced to the market when the only other major API options were Microsoft’s Direct X on Windows and OpenGL on many other platforms. The low level API provided significant benefits such as a highly reduced CPU overhead, Native Multi-GPU support, Explicit command buffer control etc. To the player, the reduced overhead and fewer direct calls to the CPU meant that the players with high-end GPU’s would be getting much better frame rates than before as the GPU was no longer held back by the CPU. But, quite similar to Metal, Mantle was also restricted to work with AMD’s own hardware, for reasons attributed to lack of industry support or internal decisions, hence the benefits of the low level API, like Native Multi GPU support, were still not felt beyond Windows machines using AMD’s hardware. Mantle was eventually shelved and AMD had officially advised developers to move out of the ecosystem. What it had achieved in its lifetime is a propulsion to move from DirectX and OpenGL to a much better Graphics API solution.
With the widespread boom of Smartphones and rise of Smartphone gaming, there was a high demand for a lower overhead API that could be ideal for portable devices. But as we saw in the previous section, most efforts were either ecosystem-bound or relying on API technology developed almost 25 years ago. There was even a significant gap to be filled for the Operating Systems that did not fall within the proprietary ones that we mentioned in the earlier section.
The Khronos Group kickstarted the development of a next-gen Graphics API in July 2014 and officially announced the project with a call for participation in Dec 2014 at the SIGGRAPH. AMD handed over their Mantle API to form the base of the next gen iteration of OpenGL from Khronos. Although they initially targeted a 2015 release, the production was delayed and the Vulkan API was officially released with specifications and SDK on February 16, 2016. As of now, Android, Windows and Linux have Vulkan SDKs available.
One of the major gains with this API will be improved visuals on Linux as well as SteamOS gaming. Even Macs will gain visual improvement because Vulkan is much better performing than Metal as a low level Graphics API. A significant concern regarding SteamOS had been the lack of optimal performance in some games, which will definitely be improved with the inclusion of Vulkan support on SteamOS. Along with the specs, Khronos has also released a set of conformance tests that each manufacturer can use to demonstrate spec compliance. On the very day when the Vulkan specs were released, Nvidia, Intel (Linux), Qualcomm (Android) and Imagination technologies (also Linux) have posted their successful results of the same tests.
Note: Both the tests and the specs are available on GitHub and the Khronos group is inviting contributions highlighting inconsistencies of different drivers so that their developers can realign the drivers.
In it’s short existence, Mantle did get the support of some AAA titles like Battlefield 4
The basic nature of an API that works at a level that is lower than the existing ones is that much of the work that was the responsibility of the drivers is now to be handled by the game engines. The advantage of this is that the game engine has significantly higher information about that exact work and can make calls that the driver itself doesn’t have the capability to do. And that allows the API to run with a much smaller, faster driver with support for features like multi-threading. For example, the multithreading support itself will directly benefit cases where the CPU has to handle a lot of load and leaves the GPU relatively unoccupied. And any application that cannot afford performance hitches can now directly include the GPU memory management into their implementation.
As we have already emphasised, Vulkan is platform independent and already supports a number of platforms. Although it is a bare bones API, Vulkan does support the addition of layers on the stack that can deal with validations and debug data. The original intent of the Khronos group is that a large number of these layers should be created by the developers. For example, A particular developer like Intel can verify parameters pertaining to their chipset to avoid functions that are known to perform bad on their devices.
To sum it up...
A graphics API is one of those pieces of technology that we don’t really bother with when setting up the latest game or preparing ourselves for our next major video hardware purchase. And thanks to developments like Vulkan, that decision has now become even safer with a universally applicable API. Combining the universal appeal of the OpenGL and the dedicated power and capability of DirectX and bringing all of that into, amongst other platforms, your smartphone, Vulkan API support is something that you should be looking forward to seeing in a lot of upcoming phones this year.