At the end of January, I was at the ISART Digital in Paris to join a panel discussion titled New Graphics APIs discussion panel at the dawn of Vulkan. The meeting was organized and chaired by Christophe Riccio from Unity and focused on the Khronos Group’s new Vulkan graphics and compute API.
The panel consisted of a mix of ISVs (Independent Software Vendors), IHVs (Independent Hardware Vendors) and platform owners with a range of experience from modern rendering algorithms to API implementation to driver implementation:
- Sébastien Lagarde (director of rendering research at Unity, previously at EA Frostbite)
- Julien Ignace (R&D rendering programmer at Unity, previously at Quantic Dream)
- Jasper Bekkers (rendering engineer at OTOY, previously at EA Frostbite)
- Cyril Crassin (research scientist at NVIDIA)
- Jon Kennedy (senior graphics software engineer at Intel)
- Adrian Bucur (senior software engineer at Samsung SERI)
We covered a number of topics, including: the type of developer Vulkan is most applicable to; how difficult it will be to integrate into existing rendering engines; and how the quality of debugging tools could affect the success of the API.
In this post, I’ll try to summarize some of the talking points and challenges I found most interesting.
Addressing OpenGL’s issues
For almost two years, a working group within Khronos was tasked with the creation of a modern graphics and compute API that addressed OpenGL’s biggest limitations, including:
- Creating a common API for all platforms (desktop, console, mobile & embedded)
- Mapping closely to modern GPU architectures
- Providing a console-like, low-overhead, explicit API
The panelists were asked if it was a good idea to design an API from scratch rather than using the OpenGL specification as a starting point. Advances in OpenGL, such as the AZDO initiative and the GL_KHR_no_error extension, demonstrated that it was possible for a lot of the CPU overhead usually associated with the API to be avoided. Creating a brand new OpenGL focused on those ideas could have given developers a decent performance boost.
However, this route wouldn’t have been without issues. For example:
- Buffer allocation and synchronization would still be done by an opaque driver. Stalls and buffer ghosting would still occur in vendor specific ways
- State would still be global. Developers would need a clear understanding of how each IHV’s GPU state is set to ensure OpenGL state is configured efficiently
- Efficient multi-threaded command submission would have been tricky to solve in an OpenGL-like API
After some discussion the panelists agreed that the direction taken was a little risky, but the Vulkan API has met all of the groups design goals within a reasonable time frame (even if it was delayed a little!).
How relevant is Vulkan to developers?
The IHVs (mostly) agreed that providing an API where memory allocations, state setting and call validation are developer controlled will enable better run-time performance while making driver behavior much more predictable across platforms, which should reduce maintenance costs.
The ISVs were less certain. IHVs have spent years optimizing their OpenGL, OpenGL ES and DirectX drivers. Approaching equivalent or better performance will require ISVs to invest significant resources to designing and optimizing their rendering engines for explicit APIs, for example efficiently caching state. Additionally, existing middleware will need to continue supporting older APIs for a long time. For now, Vulkan will be yet another standard to implement and support, which will increase the total cost of maintaining rendering engine code.
The restrictions that affect the big engines creates an interesting opportunity for the development of new middleware that can be more flexible. Oxide Games’ Nitrous engine was discussed as an example of an engine that has been able to focus on the bleeding edge of graphics APIs by starting from a clean slate. It could take a long time before the big engines approach the same efficiency.
So back to the question of who the API will be most relevant to. Engines will definitely support it, but those who have to support old APIs may be slow to evolve. It’s likely that projects with the simplest use cases will be the first to benefit. 2D rendering engines that spend a lot of time on screen, such as Google’s Skia, could support the API to reduce power consumption. Developers targeting closed systems will also have a lot to gain in the short-term from the lower overhead offered by the API. For example, those writing in-car navigation systems with tight CPU, GPU and memory budgets.
Will more vendor specific code paths be required?
Excluding extended functionality for the moment (which always requires new code paths and fallbacks), most cross-platform renderers using OpenGL and OpenGL ES unfortunately require a variety of code paths tailored to vendor specific driver behavior and to workaround bugs. The panel were asked if these deviations will be as prevalent in Vulkan renderers.
As ISVs are still dipping their toes into Vulkan, it’s hard to quantify how many code paths will be required. Theoretically, the reduced driver complexity should lead to less opaque behavior, fewer bugs and fewer reasons to implement vendor specific code paths. However, the panelists agreed that understanding and programming for the underlying hardware architecture is much more important in Vulkan than OpenGL, for example utilizing vendor specific DMA queues for optimal data transfers.
Will the quality of development tools affect the success of the API?
The ISVs agreed that the quality of development tools can have a more significant impact on an API’s success than the API itself. For example, developers frequently target Sony’s platforms and APIs first as they have (in many people’s opinion) the industry’s best tools.
OpenGL development has historically been quite difficult. There are now a wealth of utilities maintained by platform owners, IHVs, ISVs and the community, but it has taken years to reach this stage.
With the advent of Vulkan, the Khronos group has put more thought into tooling than previous standards. The loader layer design, for example, enables developers to use Khronos supplied debugging layers, those provided by 3rd parties or custom solutions. Unfortunately, Vulkan – like OpenGL – lacks canonical utilities for many debugging tasks, such as analyzing and replaying call streams. Unless the Khronos creates working groups specifically for tools in parallel to the design of new APIs, it’s unlikely this will change.
As we’ve seen since Vulkan’s release, there are already a number of tools available and many more on the way developed by Khronos Promoters, Contributors and Advisory Board members. Platform owners such as Google and Valve will provide cross-vendor tools for their operating systems. Community maintained tools, such as RenderDoc, will allow developers to debug across a variety of operating systems and GPUs.
At the end of the tools discussion, an audience member asked if GPU performance counters would be exposed through Vulkan. Unfortunately that hasn’t happened yet, but it could be addressed through an extension in the future.
The panel concluded that good tools are essential for Vulkan to succeed. The variety of proprietary and community supported tools available at launch day and shortly after should enable developers to find a debugging workflow that suits their requirements.
Should the Khronos group have also developed a high-level abstraction?
During the API’s design, the group considered developing helper libraries to make it easier for developers to get started with Vulkan.
After some consideration, it was decided that a generic abstraction would have taken too much focus away from the development of the Vulkan API.
Community provided libraries, such as the new PowerVR Framework, will give developers a variety of generic and domain specific libraries to choose from. As Khronos contributors were already planning to develop frameworks like this, the panelists agreed that a reference abstraction to coincide with the 1.0 release would have had minimal value and would have negatively impacted the timeline of the Vulkan API’s development.
Come meet us at GDC 2016 if you want to learn more
Hopefully this post has given a useful insight into the concerns of the hardware and software vendors involved in the API’s development.