Since some of you may not be familiar with the Khronos Group, let's start with some history. This non-profit consortium was founded back in 2000 by ATI, Intel and NVIDIA among others, with the goal of creating open standard APIs.

　　The latest API developed by Khronos Group is Vulkan, first released about five months ago. It's conceptually quite similar to Microsoft's DirectX 12 in that they are both focused on reduced driver overhead and reduced CPU load; its main difference is that it's fully cross-platform.

　　Obviously, Vulkan fights an uphill battle to get the attention of developers with Microsoft's Windows PC and Xbox environments (now unified under the Universal Windows Platform) often steering developers to DirectX 12. RedGamingTech had the opportunity to interview Tom Olson (Chair of the Vulkan Working Group) and Neil Trevett (President of the Khronos Group), and one of the questions was if Khronos found it hard to fight the interest in DirectX 12.

　　Tom: We’re not really trying to ‘combat’ anything – we’re trying to make a great API that can run on all modern hardware and platforms. We think it’s obvious that that’s what the market needs, and that if we do a good job, people will use it. We recognize of course that it’s about more than just the API – we have to create and support a complete solution, a whole ecosystem. Hence the emphasis on defining a standard loader, validation and debug layers, a shader compiler, and other tools, all available in open source.

　　Neil: DX12 is a fine API and it will be the right commercial choice for some developers addressing a certain set of platforms. It may not be good for readership ratings to say this – but I think the ‘API wars’ are often overblown – developer choice in APIs is a good thing. Additionally, I think that over the years healthy competition between Direct3D and OpenGL has been a positive incentive for both families of APIs to improve – which ultimately is good for the developer community. But, if you look at the industry as a whole, it is a healthy thing to have the choice of a graphics API that is not being defined by a single platform vendor, as it provides an avenue for API innovation that is independent of the underlying platform dynamics of the day.

　　They also talked about full mGPU support, which is not yet fully available in Vulkan.

　　Tom: Full multi-GPU support was definitely a goal when we launched the project, and there is some support in the API, but we weren’t able to finish the job in time for the 1.0 release. In 1.0, you can query your VkInstance and find out that it supports multiple VkPhysicalDevices, e.g. GPUs, and those can come from either the same or multiple vendors. And you can then create logical devices and queues from the physical devices, and submit work to them from a single application. What you can’t do in 1.0 is share resources or synchronize directly between different devices, so the use cases are limited. Fixing that is a high priority for us.

　　Finally, in the future the API will receive both performance and quality of life (QoL) updates by Khronos.

　　Tom: Probably a mix. We’re really eager to hear from first-generation developers about what kind of experiences they are having, and we’re pretty sure they’ll tell us that we got some stuff wrong. We’ll need to fix that as best we can. Then there are the features in GL and DX that we don’t have in Vulkan 1.0, most obviously multi-GPU support – that’s a very high priority. And there are the new application spaces, like VR which you mentioned. We’ve got a substantial list and are working actively on it.

　　Neil: Also, don’t forget that Vulkan is extensible – just like OpenGL – so we have the option of delivering this functionality in between major spec updates.

　　We'll keep following closely both Vulkan and DirectX 12 as they are adopted by the gaming industry. Stay tuned!