The Khronos Group today launched Vulkan 1.1, the first big revision of its vendor-neutral, cross-platform GPU API.

The new revision standardizes a handful of features that were previously offered as extensions. The release rounds out the API, bringing parity with Microsoft's DirectX 12 in a few areas where it was absent, improving compatibility with DirectX 12, and laying the groundwork for the next generation of GPUs.

One feature in particular goes a long way toward filling a Vulkan gap relative to Microsoft's API: explicit multi-GPU support, which allows one program to spread its work across multiple GPUs. Unlike SLI and Crossfire of old, where the task of divvying up the rendering between GPUs was largely handled by the driver, this support gives control to the developer. With the addition, developers can create "device groups" that aggregate multiple physical GPUs into a single virtual device and choose how work is dispatched to the different physical GPUs. Resources from one physical GPU can be used by another GPU, different commands can be run on the different GPUs, and one GPU can show rendered images that were created by another GPU.

This feature does have one deficit relative to DirectX 12, as it requires homogeneous GPU configurations, where every GPU must match (or at least be closely related and use the same driver). DirectX 12 goes a step further, allowing heterogeneous GPU configurations that mix and match different GPUs from different vendors. This extra capability is interesting because, though multiple discrete GPUs are still relatively uncommon and are usually found only in the most expensive gaming systems, it's very common for systems to have one discrete GPU and one integrated GPU.

Vulkan 1.1 is also better for Virtual Reality applications. VR requires rendering two different perspectives of the same 3D scene, one for each eye. This is possible today through brute force—first, submit all the commands to draw the left eye to the GPU, then submit all the commands for the right eye. With Vulkan 1.1, developers can use multiview, where a single set of rendering commands produces multiple, slightly different outputs with a single call.

Another notable feature is that Vulkan 1.1 enables the use of Microsoft's HLSL shader programs. There are differences in memory layout between OpenGL/Vulkan and Direct3D. Hardware, which has to handle both APIs anyway, can work with both layouts, but the graphics APIs previously needed things to be in their own preferred layout. With Vulkan 1.1, the Direct3D memory layouts are handled natively, and HLSL programs that assume these layouts are also handled natively. This makes it easier for developers to move existing Direct3D code to Vulkan, as they no longer need to rewrite all their shader programs.

To support this, a new version of SPIR-V (the vendor-neutral intermediate representation for shader programs), version 1.3, is being released in tandem with Vulkan 1.1. SPIR-V has also been subject to some interesting experimentation: a collaboration between Adobe, Google, and Codeplay has produced Clspv, a compiler that takes OpenCL programs and compiles them to SPIR-V. This means that programs written for OpenCL—a specification for parallel computation that spans CPUs, GPUs, and DSPs—can be run on any GPU that has a Vulkan runtime, which includes some platforms that don't have OpenCL runtimes.

The new version of Vulkan also supports new color formats; specifically, the use of the YUV/YCbCr color encodings. These encodings are commonly used by motion video codecs. This addition ties into another new Vulkan 1.1 feature: built-in support for protected content. For good or ill, both physical and streaming digital media often require their content to be encrypted and copy protected, and this requires cooperation from the display driver. The Vulkan protected content capability allows this content to be used as part of a GPU-rendered scene, while still honoring the copy protection and secure display. This, in turn, means that systems can use Vulkan for desktop composition, for example, while still supporting protected media.

The new spec also improves the programmability of GPUs with subgroup operations that allow data to be shared in a variety of ways between the different threads of a GPU-based computation and 16-bit data types, as well as supporting cross-process sharing and synchronization of GPU objects and memory.

With the exception of heterogeneous GPU support, Vulkan 1.1 represents something of a landmark. During the early- to mid-2000s, Microsoft's DirectX API arguably superseded OpenGL, both in terms of being easier to use for developers and having better support for the capabilities of modern GPUs. OpenGL, in contrast, languished. A significant effort was made to modernize the OpenGL API, but various industry factors meant that effort was derailed and abandoned. During this time, Microsoft was in some ways the driver behind new GPU features and APIs, encouraging the GPU vendors to innovate in certain areas to meet the needs of Windows.

The creation of the Khronos Group, the multi-vendor group that stewards OpenGL, Vulkan, and certain other APIs, put things back on track, and the regular iteration of OpenGL 3.x and 4.x specifications allowed the vendor-neutral OpenGL API to make up the ground it had lost relative to DirectX. Similarly, though Vulkan was released some time after Direct3D 12, it offered the same kind of low-level GPU access as Microsoft's API. Vulkan 1.1 covers virtually all the same bases as Direct3D 12, and in some areas—particularly in the use of the tiled GPUs that aren't found in desktop systems but which are the norm in smartphone processors—it surpasses the capabilities of the proprietary API.

This near-parity achieved, Khronos is no longer merely playing catch-up: it's now in a position to lead GPU design and capabilities, pushing for the features that make most sense to (especially) game developers, Web developers, and mobile platforms.