AH TechTalk: Industry Bodies Discuss Vulkan Graphcs API

Khronos is an industry body with responsibility for overseeing a number of graphics standards. Over the last few months, Khronos have been working on a next-generation graphics API (application programmable interface) technology called Vulkan, being developed in parallel on the Android, LINUX and Windows platforms. The API is described as a new “graphics and compute” code and is designed to improve the performance and efficiency of graphical content by better utilising the various cores present in modern hardware – these being processor and GPU cores. At the end of January a number of industry businesses got together in Paris to discuss the new Vulkan technology. The delegates included representatives from NVIDIA, Intel and Samsung and discussed a number of points including the type of developer able to benefit from the Vulkan API, the difficulties faced when integrating the technology into existing rendering engines and how various debugging tools might help or hinder the success of the API.

One of the first points addressed by the panel was how to manage the OpenGL issues. Vulkan has been designed to cover a number of OpenGL’s weaknesses, including creating a single API technology to cover desktop, console, mobile and embedded hardware, based upon an understanding of modern GPU technologies. This meant writing the code to cope with multiple application and GPU cores and using a console-like, low-overhead explicit API. The panel were asked why the Vulkan API was developed from scratch rather than from modifying, improving and refining the OpenGL technology – especially when OpenGL has seen improvement designed to reduce the CPU overhead and better improve the efficiency of GPU cores. The panel discussed how there were a number of technical reasons why it would be easier and more reliable to rewrite the API rather than modify existing code, including how some of OpenGL’s limitations would remain after the rewrite. The example given was how OpenGL allocates and synchronises buffers, which would need be done by an opaque driver and this meant stalls and buffer ghosting could still occur based on how a given vendors had set up the hardware. The other major reason why rewriting OpenGL was not considered viable is because it would have been difficult to set up an efficient multi-threaded command submission system – OpenGL was not designed for modern GPU architecture. Of course, the risk associated with writing fresh code is that the project may miss design objectives or be delayed.

When the panel discussed the relevance of the Vulkan API to developers, the members disagreed here. The hardware vendors almost universally agreed that providing an API to allocate memory and other hardware switches should result in both improved performance (and so efficiency) across multiple platforms. This in turn should mean that maintaining and bug-fixing issues should be easier, smoother and cheaper. Software vendors were less optimistic – the hardware vendors have spent many, many software engineer hours optimizing and refining OpenGL, Open GL ES and DirectX drivers and in order to approach similar or better performance, the software vendors will need to invest significant resources to optimise the new technologies. Furthermore, the existing OpenGL technologies will still need maintaining – the Vulkan API is another API standard that will need resources.

The panel discussed the issues and restrictions that the significant graphics engines place on graphics hardware and how it will take some time before these graphics engines are well optimised on the Vulkan API. The panel considered that in the short term, the greatest beneficiaries of Vulkan were likely to be those developers working on software that uses a 2D rendering engine – such as in-car navigation systems with limited hardware resources. The Vulkan API should allow the software to better utilise the hardware and so save power (and heat output). This is important for all hardware, but arguably more so for those machines running on battery power.

One interesting point that was raised is that the quality of development tools can have a greater impact on the success of a given graphics API than the quality of the API itself. Sony’s APIs were used as an example: Sony’s platforms and APIs are considered to be amongst the best and easiest to work with in the industry, and because of this the Sony platforms are often first to benefit from a new game. OpenGL development has traditionally been difficult although over the years, a suite of development tools and utilities has been built up to assist. Khronos has thought more about the development tools for Vulkan compared with OpenGL. The market has also moved on since the introduction of OpenGL with many companies, such as Google, offering cross-vendor tools designed to help developers. There are also community-maintained tools and utilities, with RenderDoc given as an example, that can help developers debug applications across a range of operating systems and underlying hardware. In essence: good development tools were seen as being vital in order for Vulkan to succeed.

On paper, the new Vulkan API should offer improved performance, reduced power consumption and easier development across multiple platforms. As with any standard, we can expect development to be “lumpy” during the first few months and years as individual developers and hardware vendors provide support for the technology. We’ve already seen NVIDIA and Google release software with built-in Vulkan API support and this is set to continue.