Khronos speaks to Architosh about the new Vulkan Graphics API: What it Means

Continued from page 1

Why Vulkan is Next Generation OpenGL

As acute Architosh readers know quite well, the industry open standard known as OpenGL has been instrumental to the Mac platform’s ability to flourish and grow. It has done so in the face of stiff graphics API competition from Microsoft in its DirectX API on Windows PCs.¹

Moreover, its mobile-oriented sibling API, OpenGL ES, quickly became the dominant graphics API throughout the entire mobile devices world, including handheld gaming systems and smartphones and tablets. So does Vulkan’s superior capabilities threaten established open standards? This was a key question I threw at Neil Trevett, President of Khronos Group.

“OpenGL and OpenGL ES are not going away,” says Trevett, “we will continue to advance them. And as you are likely aware, any new API takes time to be adopted in the industry and become widely used. Today OpenGL and OpenGL ES are in their adoption prime, providing developer access to billions of devices.”

Despite the initial naming, “Next Generation OpenGL” Vulkan will develop and come up, side-by-side, in the industry. Why side-by-side? Trevett explains that they are “aimed at different types of developers and it will be “interesting”—his words—to “see how the industry utilizes both and what paths get paved forward for by the Khronos Group” in order to meet developer needs.

As Vulkan advances alongside its older sibling APIs it does so with specific capabilities that both OpenGL versions are founding lacking in. Let’s review these now in detail:

Direct GPU Control: Increases Performance

Unlike OpenGL and OpenGL ES, Vulkan responds to the growing trend in allowing developers to gain direct control of the GPU hardware. Neil Trevett characterized this difference as being more “explicit” versus “a lot of work being done by the driver.” With the OpenGL API family there is a lot more hardware abstraction and driver complexity—with the traditional OpenGL driver handling significant context, memory and error management tasks. This relieves the application developer from those burdens but with it removes opportunities.

Trevett said, “A lot of demand for Vulkan was coming from the game engine developers and gaming community who want the responsibility and control to talk directly to the GPU so they can maximize every drop of performance capability.” With Vulkan, the application is responsible for memory allocation and thread management to generate command buffers. This simplifies driver development and lends itself to cross vendor portability.

Multi-threading Advantages in Vulkan: Increases Performance

Another key change from OpenGL in Vulkan is the way mult-threading works. OpenGL and OpenGL ES were very much limited in their multi-threading abilities compared to Vulkan. In both OpenGL APIs the act of creating work and submitting work were one atomic thing. You had one thread both creating command buffers and submitting them to the GPU as a single process, and as Trevett explains, “it was quite difficult to split that into a clean multi-threaded process. Whereas in Vulkan, you have this very clean split between submitting command buffers in the command queue and actually creating those command buffers in memory.” (see image 02 below)

02 – Vulkan has huge advantages over OpenGL and OpenGL ES with regards to multi-threading and performance capacities. (image: Khronos Group slide on Vulkan. All rights reserved).

In Vulkan you have have multiple command buffers sitting around in memory with multiple threads, in addition you can have a separate thread actually doing submissions. This clean separation means that software developers can dive in deep and optimize their code for profuse multi-threading, and there is virtually no limit to the amount of threads (other than memory) you can have submitted from the command buffer.

Trevett says, “Even smartphones today can have 4 CPU cores onboard, so the thing that has been hard to get around with OpenGL was multi-threading, to gain faster performance and speed.”

SPIR-V and Shader Langauges

Since OpenGL 2.0 the technology itself has shipped with its own compiler. With Vulkan the compiler chain has been split in two, liberating the front-end and back-end of the process that ultimately takes high-level programming languages and translates them to low-level languages hardware GPUs understand.

Eliminating the need for a high-level language source compiler significantly reduces GPU driver complexity. Furthermore, the adoption of SPIR-V will help shepherd in an era of a wide diversity of language front ends. (see image 03) Trevett explained that SPIR-V is the third generation of SPIR (which was originally created for OpenCL) and in the first two generations the Khronos Group used LLVM (low-level virtual machine) which itself is a significant contemporary compiler project very much associated with Apple at the present moment.

03 – The Vulkan computer language ecosystem will grow diverse yet bring simplification and quality to driver backend. (image: Khronos Group, all rights received.)

Trevett explained that the Khronos Group will actually have translators between LLVM and SPIR-V, but SPIR-V does not use LLVM—and is the first cross-vendor IR built to support graphics and parallel constructs—and can support multiple languages including the OpenCL 1.2 and OpenCL 2.0 C-based kernel languages, and the new C++ based kernel language for OpenCL 2.1 as well as the GLSL shader language for Vulkan.

GLSL stands for OpenGL Shader Language, the computer language developers use for writing shaders for their programs. For Architosh readers in particular, recall that your 3D and CAD programs render your objects using various formats (e.g.: flat shading, phong shading, etc) so shaders are, in actuality, little programs in themselves telling your computer how to draw something specific for every pixel that makes up your scene.

Neil Trevett said that a C++ compiler language has been the number one request from the OpenCL community behind the development of SPIR-V and added, “the C++ kernel language work using SPIR-V for OpenCL means we quite probably are going to end up with a C++ graphics shader language for Vulkan—which will be welcomed by many developers.”

next page: Adding It All Up