The Vulkan graphics API [LWN.net]

By Nathan Willis
February 17, 2016

The Khronos Group, which (among other things) maintains the OpenGL specification, has released version 1.0 of its new cross-platform graphics API, Vulkan. The Vulkan API is designed to be a lightweight API—at least in comparison to OpenGL—that provides graphics processing and general-purpose GPU computation. A number of open-source projects have announced Vulkan support already, although it may be some time before it can be put to the test in a major way on the average Linux system. In the long run, however, Vulkan promises higher performance on modern GPU hardware, simplified driver development, and a single API that covers all device profiles, from embedded systems to desktops.

Many of the ideas in Vulkan originated in AMD's Mantle API project, which was started in 2013, but shut down in 2015. Mantle was, understandably, an AMD-only effort, but its goals were of interest to graphics-software developers on many hardware platforms: build an OpenGL-like API from the ground up that dispensed with years' worth of legacy architecture no longer applicable on modern hardware.

For Linux users, the parallels to Wayland and X11 are clear. As with X, OpenGL was initially devised for hardware and software stacks that look very different from what is commonly deployed today. The Vulkan project targeted the same ideal as Mantle and eventually incorporated much of AMD's work on the subject. Still, Khronos took Vulkan from inception to a first release in a relatively fast 18 months, delivering drivers, demo code, and open-source software-development kits (SDKs) in conjunction with the specification.

What's available

The specification itself is available on the Khronos site as well as in a GitHub repository. The drivers available at launch time include offerings from a variety of companies that cover desktop and embedded Linux, Windows, and Android. On the desktop Linux side, Intel has released drivers for its fifth- and sixth-generation Core processors; NVIDIA has released drivers for the Kepler and Maxwell GPU families (essentially the GeForce 600 and later). For Android and embedded systems, Qualcomm has published a driver for the Adreno 530 GPU (found in the Snapdragon 820), and Imagination has developed drivers for PowerVR. So far, AMD has only released a Windows driver.

The NVIDIA drivers are proprietary, and available for both 64-bit and 32-bit systems. The Intel drivers are free software; they are available in the Mesa Git repository and have been packaged for Ubuntu and Fedora. Apart from the drivers themselves, Vulkan defines a Window System Interface (WSI) that provides hooks for various window systems. Included in the 1.0 WSI specification are Wayland, X11, Mir, and Android. There are two SDK options available; one is the official Vulkan offering from LunarG and includes desktop Linux and Android, the other is Google's Android Native Development Kit (NDK), which now includes Vulkan support.

In addition, support has already begun trickling into other libraries. Matthew Waters announced a GStreamer video sink element that uses Vulkan.

What's inside

With all of that code available, the natural question to ask is what Vulkan 1.0 provides that OpenGL does not. In a sense, Vulkan is designed to be a successor to OpenGL, offering a cross-platform interface to GPUs for 3D rendering, video and graphics processing, and parallel computing. In another sense, though, Vulkan is positioned to serve as an OpenGL alternative that is tailored to use cases that need to squeeze as much performance out of the hardware as possible. For those applications, ditching OpenGL's overhead is paramount. For other programs, however, Vulkan's stripped-down design means considerably more work.

There are four large pieces of the OpenGL specification that are cut away in Vulkan: memory management, error handling, validation, and diagnostics. Strictly speaking, the validation and diagnostic layers are optional in Vulkan, but for performance-sensitive applications, the inability to run without them in OpenGL was a drawback. Dispensing with built-in memory management and error handling places a heavier burden on the application but, in turn, it removes the OpenGL-context management and memory management code from the graphics driver.

In addition, Vulkan is designed to support multi-core CPUs with full multithreading. In Vulkan, threads can each create their own command buffer, and all of the buffers feed into the same queue. Here again, the application is responsible for its own synchronization and thread management, but OpenGL is hampered by the need to maintain a single context, which can leave CPU cores sitting idle.

For a lot of GPU-intensive use cases, the critical part of an OpenGL application is the shader, the program that runs on the GPU itself. OpenGL required that shaders be written in a device-independent language called OpenGL Shading Language (GLSL), in source form. The OpenGL driver was required to compile the GLSL into machine code for the device, thus both making the driver more complicated and making it impossible to pre-compile the shader.

Vulkan replaces GLSL with an intermediate representation called Standard Portable Intermediate Representation (SPIR). Shaders can be written in any language and compiled to SPIR offline. Earlier revisions of SPIR were designed to be compatible with the LLVM compiler's intermediate representation, although the current version, SPIR-V, no longer maintains that compatibility guarantee. The SPIR-V tools support compiling Open Compute Language (OpenCL) kernels as well as GLSL shaders. Finally, Vulkan offers only a single API, which is shared by the desktop, Android, and embedded platforms. Thus, there should not be a need for developers to wrangle OpenGL and OpenGL ES for a single application.

What next

At this point, applications that need to drive as much performance as possible out of the available hardware will likely find Vulkan an easier API than OpenGL for optimizing GPU performance. The primary use case thus far seems to be the gaming market; it is no coincidence that Valve (developers of the Steam game-distribution service) funded the development of the Vulkan SDK.

But the smaller or simpler an application is, the less appealing it will be to handle GPU memory allocation and error handling internally. In its press materials, the Khronos Group touts that Vulkan will attract a rich ecosystem of libraries and frameworks that provide the higher-level functionality encoded in the OpenGL specification but omitted from Vulkan. That is likely the case, particularly if OpenGL is destined to be phased out. But, for now, the further away one gets from the GPU hardware, the less Vulkan has to offer. Simpler drivers are, no doubt, a win, as is support for multithreading. The performance gains of switching to Vulkan, though, are likely reserved for gaming engine developers in the near term.

to post comments

The Vulkan graphics API

Posted Feb 18, 2016 12:14 UTC (Thu) by excors (subscriber, #95769) [Link]

> The performance gains of switching to Vulkan, though, are likely reserved for gaming engine developers in the near term.

I think one of the potential gains is more consistent framerates for GPU-accelerated UI frameworks. An OpenGL driver might randomly decide to recompile a shader or upload a texture or make a shadow copy of a vertex buffer, on the main thread, while you're trying to draw a 60fps animation. Vulkan makes most of that work explicit so the application can choose how to schedule it, and makes most of it available on separate threads so it doesn't need to interrupt the rendering.

I suspect it should also let you reduce UI latency - OpenGL drivers can choose to let the CPU run a few frames ahead of the GPU, to smooth out variations in CPU frame timings, while Vulkan gives the application control over that.

> There are four large pieces of the OpenGL specification that are cut away in Vulkan: memory management, error handling, validation, and diagnostics.

I don't think OpenGL really did much error handling, it just did some error *detection* in the API calls and returned an error code for the application to usually ignore. And since that error detection was always enabled, it couldn't afford to do any expensive validation. Vulkan gets rid of most of that minimally-useful error detection, but adds much more robust support for optional validation layers that can intercept all API calls and do more advanced checks (and the open source SDK includes a bunch of those validation layers).

(For non-optional safety requirements like preventing a process from reading a different process's sensitive data on the GPU, Vulkan relies on the memory protection hardware inside modern GPUs - the worst that can happen is an application will crash itself. That's why it can let the drivers be more relaxed about API usage errors than OpenGL was.)

I think what's more interesting is the parts that Vulkan has cut away from the drivers and added into the specification: memory management, synchronisation (the application has to help with all the barriers and cache operations inside the GPU, and between the GPU and CPU) and tile-buffer usage (for tile-based mobile GPUs) look like the biggest ones to me.

> Earlier revisions of SPIR were designed to be compatible with the LLVM compiler's intermediate representation, although the current version, SPIR-V, no longer maintains that compatibility guarantee.

More specifically, SPIR 1.2 was heavily based on LLVM 3.2 bitcode, and SPIR 2.0 was heavily based on LLVM 3.4 bitcode, but LLVM intentionally offered no guarantees of compatibility or easy translatability between different versions of its bitcode, and didn't define the bitcode precisely anyway, so SPIR wasn't standard or portable. SPIR-V is a totally new binary format which is specified in a lot of detail, and is designed to be translated to any version of LLVM bitcode or to any other compiler IR, which seems like a much more sensible design.