announced a few months ago the Vulkan API, a project aimed at replacing OpenGL, and starting from a clean slate in terms of graphics programming. We had the opportunity to have a chat with Neil Trevett, President of the Khronos Group, to talk about the future!
- First of all, when and how did the Vulkan project start?The Vulkan working group started work in June 2014 when it became clear that industry was ready for a ground-up re-design of GPU APIs. There is a lot of energy and effort going into defining Vulkan – it is not a normal, multi-year, standardization effort – it will be completed much faster than that… - Vulkan will “replace” OpenGL, but its perimeter is different too. How was it defined, and how did you avoid "requirements creep"?The key design goals for Vulkan are to reduce driver complexity and overhead to provide a portable and predictable API platform with maximum flexibility and performance as demanded by advanced applications, middleware and engines. Because time is of the essence, we are ensuring that Vulkan 1.0 delivers all the essentials for a new generation API and sets a firm foundation for future evolution – but deferring any non-essential features to future versions. In any case we need real-world experience and feedback from Vulkan 1.0 to make data driven decisions for potential new features. - Many people think DirectX initially "won" against OpenGL due to its early focus on gamers.One could argue that the OpenGL family – which includes OpenGL, OpenGL ES and WebGL – and providing access to GPU acceleration on billions of devices and platforms “won” in the wider sense. But actually we welcome healthy competition between open standard and proprietary APIs – as it pushes both forward. - Is that why so many game studios are now involved in Vulkan?In general, independent software vendors benefit from having to code, optimize and support their applications, libraries and engines on a minimum number of low-level APIs. Hardware vendors can also reduce costs, in general, by having to support a minimum number of low-level APIs. Hence the overall desire to prevent industry fragmentation through open standards, and the wide industry support for Vulkan from both the hardware and software communities. - What are the most important hardware trends that Vulkan has to take into account?Many key hardware trends are being driven from mobile devices and the single Vulkan framework is designed to support, mobile, embedded and desktop systems - there will be no need for a ‘Vulkan ES.’ Some of the key architectural considerations include: tiling renderers are common in mobile and have to be supported as efficiently as immediate mode architectures; a unified memory rather than a traditional PC with a PCI-Express bus between the CPU and GPU enables radically new memory management strategies; and multi-core devices are now very common – so it is essential that Vulkan enables effective multi-threading performance – something that, in the end, was not fixable with OpenGL’s monolithic context management system. - Vulkan API is more low-level than OpenGL (programmer is responsible for memory and threads management for example), what triggered this decision?A low level API has simpler drivers. This means reduced driver overhead – which results in higher performance for CPU limited applications – and fewer differences between multiple GPU vendors’ implementations. Also, another fundamental advantage of handing the application more control is that the driver has to do less ‘behind the scenes’ management – resulting in much more reliable and predictable performance which doesn’t hit unexpected road bumps as the driver undertakes complex housekeeping tasks. - Some people fear that the low-level character of Vulkan means there is no real hardware abstraction, which could be a problem for desktop 3D application developers (ex: Blender). Should we infer that Vulkan is for games and OpenGL for other desktop applications?No – this is not the right way to look at things - Vulkan absolutely defines a hardware abstraction – it is just lower and more explicit than OpenGL. It is an interesting design challenge to keep the level of abstraction low, but still provide portability across multiple architectures. Many professional design and authoring applications are also CPU limited – and those software developers are very interested in Vulkan and participating in the working group. Vulkan will replace all uses of OpenGL over time – potentially quite a long time – and for those developers that do not need all the flexibility that Vulkan provides – there will be libraries and engines that layer over the low-level API. - If I understood correctly, the point of not having hardware abstraction is to have more predictability, at the expense of more complexity in the software you’re writing. Could that be a problem for smaller game studios?As we mentioned above, Vulkan does define an abstraction – albeit a low-level one. Application developers have to take more control – which is more involved in some ways – but real world developers spend much of their development time battling driver inconsistencies and unpredictability – and in that respect that a Vulkan app could be actually easier to use to get fully debugged, and reliably performing across multiple platforms. For developers that don’t need all of Vulkan’s flexibility, there will be utility libraries and engines that will provide a much higher and familiar level of programming. - What concrete improvements will gamers see, when Vulkan is used by video game studios? Can they expect better performance and better graphics, or is it just about simplifying studios backend work?For applications that are CPU limited, which happens on desktop, and even more on mobile, end users should notice better performing applications with less stuttering and halting. - When will Vulkan first version be released?Vulkan is still on schedule to have specs and implementations before the end of the year.- Shall we see JS frameworks to make Vulkan calls from the browser, like WebGL with OpenGL?Vulkan is being watched very carefully by the WebGL working group but it is too soon for any roadmap decisions by the browser vendors. In any case the WebGL working group will need Vulkan to be pervasive before it can be supported in production browsers. Personally I think there will not need to be a ‘WebVulkan.’ WebGL will continue to absorb capabilities of underlying APIs as it does now – when it can so in a pervasive and portable way.