Vulkan 1.1 Specification Released: Open-source Tools, SDKs, and Launch Driver Support

Since the release of Vulkan 1.0 in February 2016, the successor to OpenGL slowly but surely made its way into applications and game engines. Today, roughly two years later, the Khronos Group is releasing Vulkan 1.1 and SPIR-V 1.3 specifications, and much like Vulkan 1.0’s ‘hard’ API launch these are accompanied by updated developer tools, open source conformance tests, and launch driver support from GPU vendors.

While adoption may not have been as fast as some users would have liked, Vulkan 1.0's feature-set and functionality was never the issue. As opposed to the Microsoft-supported DX12 and Apple-supported Metal, the Khronos Group industry consortium is comprised of member companies that ratify specifications, and do not offer the same kind of unified development resources, tools, and tutorials.

With that in mind, where 1.0 primarily emphasized the software and specifications themselves, the Vulkan 1.1 release is coupled with further development of the Vulkan ecosystem, with Khronos announcing a new public “Vulkan Ecosystem Forum” to facilitate developer feedback and collaboration. And this also ties in with Khronos’ efforts to expand platform support, where just last week an open-source collection of tools and libraries were released to port Vulkan applications to macOS and iOS, as part of the Vulkan Portability Initiative.

In sum, the evolution of Vulkan from 1.0 to 1.1 is three-pronged: integration of developer-requested functionalities, driver support and seamless porting of Vulkan to more platforms, and then practical implementation by way of a developed ecosystem.

Vulkan 1.1 Spec Highlights

Moving straight into the core changes, Vulkan 1.1 brings two new wide-ranging functionalities: protected content and subgroup operations. The former utilizes low-level restrictions such that applications can render and display using resources they cannot access or copy, in turn securing playback and display of protected content. While ostensibly for DRM purposes, Khronos noted that Vulkan was exposing GPU capability rather than pushing for hardware-level DRM, leaving usage or implementation up to the developers.

So on the one hand, developers may choose to create a highly-restrictive multi-layered DRM scheme with a high degree of granularity. On the other hand, perhaps the feature could be used for an advanced low-level adblocker, not only for browsers but one that could hook onto ad-serving mobile and desktop games and applications. All might be possible with Vulkan 1.1 and beyond. To that end, Vulkan is in many ways simply looking to enable what is possible – in the purest sense of the idea – on GPUs.

That idea carries over with the new ‘subgroup operations’, where a set of threads can communicate and coordinate amongst themselves where normally this would be done by accessing off-chip memory. Ultimately, this offers developers a method of parallelizing certain workloads to a very high degree, and while compute and deep learning are the more obvious use cases, subgroup operations are not limited to only compute shaders and could presumably be used for graphical purposes. Naturally, the new SPIR-V 1.3 likewise supports subgroup operations. (ed: this all sounds very Volta-ish, though I expect future GPUs to implement the underlying tech as well)

The other 1.1 core integrations to come from pre-existing extensions, which are now being promoted to the most integral level of extensions within the API. Many of these extensions are focused on VR or enhanced versatility of some kind, including simultaneous rendering to multiple image views (e.g. multi-projection acceleration), cross-API and cross-application/process interoperability, YCbCr support, and device groups for homogenous multi-GPU configurations.

Molding a ‘Vulkan Ecosystem’: More Support, Better Tools

For all the specs and features, Vulkan is still an API, powering other applications, engines, and games. In the two years since Vulkan 1.0’s release, a variety of new Vulkan-powered mobile and cross-platform desktop games have continued to trickle out; while acknowledging the potential issues with citing Wikipedia, Khronos does point out that there are comparable amounts of DX12 and Vulkan enabled games rather than a significant DX12 majority. By our own reckoning there are definitely more AAA Windows games where DX12 is the favored API, but thaks in part to the slow adoption rate on both sides, it's not nearly as lopsided as Direct3D vs. OpenGL was.

But as a proprietary solution supported monolithically by Microsoft, DX12 has a wide range of centralized and pre-existing resources. Additionally, DX12 can be directly pushed by way of Microsoft Studios and UWP. Meanwhile, Khronos is an industry consortium and naturally does not possess in-house development capability or offer that kind of direct developer support.

Doubling-down on the open-source approach, Khronos is likewise recreating an open ecosystem with the new “Vulkan Ecosystem Forum.” Being in communication with developers from other platforms as well as the API designers and working groups of Vulkan itself, the forum would ideally bring a degree of centralization and source of active developer progress without imposing a specific mandate, much like the Vulkan spec itself. As more platforms are brought into the fold, through the Vulkan Portability Initative or otherwise, the Forum can serve as a centralized source of cross-pollination for multi-platform developers. The Forum would also provide open-source projects with sustained guidance, which would be particularly useful for smaller projects that could become very useful.

This approach also demands more of guides, resources, and tools as they would not be reviewed, packaged, and supported monolithically. In that sense, Khronos and LunarG are announcing several new Vulkan developer tools, including a Device Simulation Layer. And with more than two years of experience with Vulkan 1.0 and its idiosyncrasies, Khronos and LunarG have refined their best practices enough to make an Assistant Layer to guide both newer and older developers with situations not directly covered or prohibited by the Vulkan spec.

The other point that Khronos reiterated was on competition between Vulkan and DX12. Rather than clashing head-to-head, Khronos viewed each API has having different use-cases and strengths with some overlap. For UWP-only developers, there is little reason to consider Vulkan, while developers looking to deploy across multiple platforms may not want to limit themselves with DX12. With the Vulkan Portability Initiative and gfx-rs in particular, Khronos is aiming to implement Vulkan over D3D12, Metal, and OpenGL.

While some have perceived these Vulkan Portable subsets as another example of a universal standard that only becomes another competing standard, Khronos explicitly mentioned avoiding that approach. Because of the commonalities between Metal, DX12, and Vulkan, as well as Vulkan’s modularity with layers and inherent cross-vendor cross-platform versatility, Metal and DX12 can be treated as subsets of Vulkan. In that way, Khronos can simplify the equation by enabling developers to build on Vulkan and easily port it elsewhere.

In these ways, Khronos is tackling what they see as their largest obstacle, the Vulkan ecosystem. Moving forward, Khronos sketched out a general 1 to 2 year cadence for Vulkan core and corresponding SPIR-V updates, with extensions being trialed, integrated, and debugged all along the way.

As for launch drivers, Khronos noted that AMD, Arm, Imagination, Intel, NVIDIA, and Qualcomm all had conformant Vulkan 1.1 drivers. Links will be updated as they become available.

The Ecosystem Forum can be found on its specific GitHub page, while the updated LunarG SDK and tools layers are also available. All Khronos open source projects can be found through the general GitHub.