Vulkan 1.1 out today with multi-GPU support, better DirectX compatibility

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.