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.

Source: Khronos Group

POST A COMMENT

33 Comments

View All Comments

  • ZolaIII - Wednesday, March 07, 2018 - link

    Theirs a list of games that use it on Wiki.
    https://en.m.wikipedia.org/wiki/List_of_games_with...
    Reply
  • HStewart - Wednesday, March 07, 2018 - link

    To me it looks like ports of older games mostly on non-Windows system Reply
  • ZolaIII - Thursday, March 08, 2018 - link

    Well list isn't complete. But older games? Some aren't yet sean official release. Reply
  • tuxRoller - Thursday, March 08, 2018 - link

    Only the first two games were pre-2013 (quake, Roblox). Then you have dota2, rust, grid, etc. Additionally only 11 of the 34 games aren't available for Windows (of those, 5 aren't yet released). Reply
  • Bulat Ziganshin - Wednesday, March 07, 2018 - link

    Note to Editor: sub-group is their OpenCL terminology for warp/wavefront, i.e. one full SIMD register. Note that even slide says about 32/64 subgroup width.

    The point is that such functionality was implemented as old as 2009 (NVidia Fermi), and probably 2011 (GCN) - 2012 (IvyBridge). It is supported in CUDA since then, but OpenCL still doesn't have standard sub-group operations, although they are available as Intel-specific extension. May be AMD also supports some extension, and they can also be implemented as GPU-specific asm commands, but there was no standard OpenCL support until now.
    Reply
  • HStewart - Wednesday, March 07, 2018 - link

    One thing I am curious as a developer - is that it appears Vulkan came from Mantle ( or at least that AMD'ers like to say ) but how much is the big boys in the industry NVidia, Intel and Microsoft are actually in it. From Vulcan wiki - it appears Microsoft is not promoter but both NVidia and Intel are along with others. The big question is? Does Vulkan give AMD GPU's an Advantage or say NVidia or is actually fair to all GPU based on GPU capabilities? Also how much overhead does Vulkan put on application over going directly to it? Also if say using NVidia GPU, can application go around Vulkan for parts where it does not handle as efficiently?

    The big concerns does this API give AMD cards advantage or not? if so I don't believe developers will use it.
    Reply
  • frenchy_2001 - Wednesday, March 07, 2018 - link

    No, no advantage in the long run.
    AMD gave Mantle to Khronos and this is the base Vulkan is built on. This gave AMD an early advantage which reflected on AMD having full Vulkan drivers before nvidia.
    Now though, both are at the same point (fully working drivers) going into that new revision.

    Nvidia fully supports Vulkan, same as AMD.
    Reply
  • HStewart - Wednesday, March 07, 2018 - link

    Let's say you have NVidia or AMD DX12 card, can you switch between native drive or DX12 support. Also these may depend on how game is designed can one switch between DirectX and Vulkan. Reply
  • ZolaIII - Thursday, March 08, 2018 - link

    You can't combine them & you can run one or the other only if app is written for them. Reply
  • testest - Wednesday, March 07, 2018 - link

    Vulkan does not give AMD an advantage in the way that it detriments Nvidia. Vulkan allows asynchronous computation API calls, multiple programs can be called to run at the same time on the GPU. Currently, even in CUDA, you cannot run multiple programs at once with Nvidia cards, you are forced to context switch the entire GPU. Nvidia does not currently have the ability to asynchronously run multiple programs even with completely different Streaming Multiprocessing Units. AMD on the other hand can actually run multiple programs at once on their latest GPUs, resulting in higher GPU utilization. It isn't a "Oh I see you're on the red team, let me give you a little boost". Reply

Log in

Don't have an account? Sign up now