Khronos unveils Vulkan: OpenGL built for modern systems

The Khronos Group announced today Vulkan, its next generation API for high performance 3D graphics and GPU-based computation.

Vulkan, previously known as Next Generation OpenGL or just GLnext, is designed to be a low-overhead API that facilitates multithreaded 3D development, enabling different threads to simultaneously prepare batches of commands to send to the GPU. It gives developers greater control of generating commands, putting tasks such as memory and thread management in their hands rather than relying on video drivers to handle these responsibilities. In so doing, it greatly reduces the amount of work that the driver must perform.

The new API was created to make it a better fit for modern hardware: GPUs are complex, highly programmable devices, and CPUs have abundant cores and multithreading support.

It represents the fourth graphics API aiming to offer this kind of control and the performance gains that come with it. AMD's Mantle, Microsoft's DirectX 12, and Apple's Metal were all developed with similar goals in mind. However, these are all platform limited in one way or another; Mantle only works with AMD GPUs, DirectX 12 only works in Windows, and Metal only works in iOS. Vulkan will span both GPU and operating system vendors, continuing in the footsteps of the cross-platform, vendor-neutral OpenGL before it.

Vulkan is also intended as suitable for both mobile and desktop development. This is in contrast to OpenGL, which has the OpenGL ES variant for mobile and embedded systems. The duality is in part due to OpenGL's age; it includes old features that aren't really relevant to modern 3D programming, but which nonetheless remain part of the specification. OpenGL ES removes many of these to be a little slimmer and more streamlined. Vulkan will similarly do away with them, eliminating the need for a special mobile API variant.

With Vulkan, Khronos also hopes to simplify drivers in other ways by changing the way shader programs are compiled. Traditional OpenGL requires each display driver to contain a full compiler for shader programs written in the C-like GLSL shader language. This is complex, with ample room for bugs. Microsoft's Direct3D took a different approach; shader programs are compiled once, by the developer, into a bytecode. Display drivers only need to process this bytecode, which is a simpler task.

Vulkan drops the OpenGL way of handling shader programs in favor of the Direct3D approach. Developers will compile shaders into an intermediate form called SPIR-V, and it is this intermediate form that drivers will work with.

SPIR-V is a new spec developed in tandem with Vulkan. It's an update to SPIR 2.0, which was finalized last August.

SPIR has previously been Khronos' intermediate language for compute shaders, used for harnessing the GPU's power for non-graphical workloads using the OpenCL API. It's analogous to the Direct3D shader bytecode, but for compute tasks rather than graphics ones. It's useful for similar reasons, too. OpenCL supports developing these programs using a C-like language, but this is complex for OpenCL drivers, as it means that they must support compilation of that C-like language. Further, many developers do not want to use C.

SPIR provides a solution. Compilers can emit SPIR intermediate code, and drivers can process that directly. This avoids both the complexity of supporting the C-like language, and it gives developers much more flexibility: there are, among others, JavaScript, C++, Python, Java, and Haskell-based languages for writing these GPU compute programs, with the compilers producing SPIR code.

SPIR-V unifies graphics and computation. Both OpenCL 2.1, also announced today, and Vulkan will ingest programs in SPIR-V intermediate code. These could be graphical shader programs originally written in GLSL, they could be computational shader programs originally written in OpenCL C, or they could use alternative development languages; they'll all be compiled to SPIR-V. As such, display drivers will only need to handle one shader language.

As well as SPIR-V, OpenCL 2.1 also includes support for writing GPU compute programs in a specialized subset of C++.

OpenCL 2.1 is available today as a provisional specification. Vulkan is available as a preview, and later today in San Francisco at GDC, Valve and others are going to demonstrate early 3D engines based on early Vulkan drivers and code. The final Vulkan specification, along with the first wave of drivers to support it, is expected later this year.

OpenGL won't go away. The lower level control afforded by Vulkan means that it may not be a good fit for all programs. For them, traditional OpenGL, with the driver handling a greater part of the workload, could be the better fit. A similar situation exists with Direct3D 11 and 12. As such, OpenGL (and Direct3D 11) will continue to have a developer audience, and Khronos intends to continue OpenGL development going forward to meet the needs of this audience.

The forthcoming existence of both Vulkan and DirectX 12 does have one consequence—it will render AMD's Mantle largely obsolete. Mantle was an early attempt at offering the same kind of optimization and efficiency that Direct3D 12 and Vulkan strive for, but being AMD-specific, it's inevitably going to fall behind in developer interest and uptake.

As such, Mantle's future looks a little unclear. New games supporting Mantle are likely to come out this year—right now it's the only one of these high performance APIs that's actually usable on the PC—but AMD yesterday told developers that going forward, if they're after the kind of features and capabilities of the current Mantle API, they're better off investing their time in Microsoft's or Khronos's API. AMD originally intended to release a public SDK (it's currently private, and only available to selected partners); that looks unlikely to happen now, in favor of providing guidance for these other APIs.

However, the company stopped short of saying that it would discard Mantle entirely. AMD writes that Mantle "must take on new capabilities" and will "continue to serve AMD as a graphics innovation platform available to select partners with custom needs." This suggests that the API will stick around in private, and it may serve as a testbed or showcase for AMD-specific capabilities or innovations.