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

Prior to the Game Developers Conference (GDC), which happened last week, Neil Trevett, Vice President of Mobile Ecosystems, NVIDIA and also President, Khronos Group, spoke with me about what the new Vulkan API means, how it relates to existing standards like OpenGL and OpenCL, and what the industry consortium’s hopes and goals are for it in the years to come.

Architected for the Present Future

The future of technology from this present looks like this—an expanding universe of computer-based devices all connected to the Internet and many, if not most, using some form of a graphical user-interface. When present graphics APIs were originally architected decades ago their authors were responding primarily to the world of personal computers, workstations, and advanced visualization systems.

Flash forward to our present and the Internet of Things illustrates a different picture. GPUs are being used to power computers, smartphones, gaming systems, robots, drones, smart TVs, smart watches, rendering servers, automobile and aeronautical infomatic systems, and a vast array of industrial computer controlled equipment (e.g.: GPUs for input processing—mainly for neural net acceleration—as well as outputting graphics).

Enter Vulkan™, which was previously named the Next Generation OpenGL Initiative. In addition to an acknowledgement of our present future, Vulkan accomplishes and addresses the following:

• Direct control over GPU operation, with minimal driver overhead for maximum performance
• Multi-threading-friendly architecture–drives overall system performance
• Designed for wide variety of devices (see image 01 above)
• Uses Khronos’ new SPIR-V™ intermediate representation (IR) for shading language flexibility and simplified drivers (see more on SPIR-V below and here)
• Extensible layered architecture–enables and encourages innovative tools
• Simpler drivers for low-overhead efficiency and cross vendor portability

It is important to note that Vulkan isn’t just a graphics-oriented API (application programming interface) but also a GPU compute API as well. This essentially means that Vulkan uses a system GPU (your graphics card’s processor) to do parallel processing for intensive computation workloads.

How Vulkan Differs from OpenCL

However, there is a difference with regards to OpenCL, the Khronos Group’s other compute-oriented industry standard. As Neil Trevett explains, “Today the key difference is that Vulkan is primarily focused on accessing acceleration on a GPU or multiple GPUs whereas OpenCL has more heterogenous flexibility and can put to use, simultaneously, not just GPUs and CPUs but also a wide variety of other devices, including DSPs, FPGAs and so on.”

Readers may recall that Apple originally invented OpenCL and that OpenCL competes with Nvidia’s CUDA for advanced parallel compute. Moreover, as we’ve noted in our recent feature on our Mac professional workstation survey (see, “Architosh publishes Mac professional workstation survey results,” Architosh, 31 Jan 2015) many professional Mac users have key workflow applications that rely heavily on Nvidia’s proprietary CUDA parallel computing platform.

Vulkan now offers a range of incentives and features that will in fact compete with both Nvidia’s CUDA, OpenCL, and even Microsoft DirectX technology, but in different ways for different reasons. The subject of GPU compute is rather complex and we’ll come back to that towards the end of this article.

next page: Why Vulkan is Next Generation OpenGL

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)

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.

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

Adding It All Up

Getting back to GPU compute. The subject can be divided in three ways—on the APIs available. On the desktop market Nvidia has its proprietary CUDA parallel compute platform. AMD on the other hand has been strong in supporting OpenCL, which Apple invented and then shared as an open-standard. And now we have Vulkan. Here’s a way to characterize all three:

• CUDA — hardware proprietary (only works with NVIDIA GPUs), brings high performance parallel computing to a specific vendor’s GPUs across multiple platforms.
• OpenCL — fully open standard based API bringing high performance parallel computing to both GPUs, CPUs, DSPs, and other hardware. It’s strength is its heterogeneous capacity. A developer can write a program that uses OpenCL to avail itself across a mixture of both GPU and CPU for maximum parallel compute
• Vulkan — fully open standard based API for graphics and compute. At first glance it may appear Vulkan combines the attributes of OpenGL and OpenCL. But Vulkan isn’t heterogeneous and therefore can’t use or combine with CPUs alongside GPUs.

As Neil Trevett stated in our call, “the tight integration of graphics and compute under one API is very powerful for some types of applications.” The key word is “types” as each API above as a compute-capable API offer difference strengths and weaknesses. As Trevett explained, “Companies like Adobe using OpenCL can—for the first time—develop complex applications that have a single code tree that supports software only and accelerated versions.”

Of the three APIs above it will be CUDA, behind its walls, that likely will be least impacted by Vulkan, at least initially once Vulkan is on the market. CUDA has a wide base of professional application support and its own ecosystem. Additionally, CUDA can often innovate faster because it doesn’t need to go through standards groups and shares the benefit of “proprietary language plus proprietary hardware.”

This doesn’t mean Nvidia’s support of Vulkan is symbolic or compromised in any way. “From Nvidia’s point of view we are very supportive of open standards,” adds Trevett, “we do support OpenCL and we believe in giving developers choice.”

The Choice: Vulkan or OpenGL?

Back to graphics, the choice to support Vulkan as an app developer, OS maker, or other third party will vary.

“For some performance is what matters most, while for others…faster times to market maybe more important,” says Trevett. And it depends on the types of markets we are talking about. When Khronos tried to take OpenGL 3.0 in a more explicit direction allowing more direct connection to the hardware to maximize performance, a revolt erupted within the industry consortium by the CAD developers. Khronos ended up revising the 3.0 spec to appease the complaints.

What games need for 3D graphics and what CAD and DCC (digital content creation) need for 3D graphics are, generally speaking, quite different. Most CAD and DCC developers will continue to find OpenGL and OpenGL ES most useful for their software applications, while a minority of them will be quite interested in taking advantage of Vulkan. Game development has different needs than the CAD and DCC developer community; though their technologies overlap their users have vastly different concerns and priorities.

Vulkan has emerged as the fourth new GPU API system that is oriented at getting down to the metal (being low-level), with less hardware abstraction layers, unlike OpenGL. “For the first time the games engine community has come forward and been instrumental in steering the new Vulkan standard into the explicit direction,” says Trevett. The games community is painfully aware of how powerful GPUs have become and what they can actually do with them for their games.

In response to all of this pressure, AMD initially created Mantle, an explicit-oriented graphics API. After Mantle, Apple and Microsoft announced their explicit-oriented APIs in Metal and DirectX 12.²

Final Take Away

It’s as if the gaming community said, “enough is enough” and all the major players said “game on” and announced their low-level, explicit graphics APIs aimed at serious performance advancements. The CAD and DCC developer community was just going to have to deal with it. And yet it shouldn’t surprise anybody that the gaming world is driving the cutting edge in software (and hardware) graphics technologies.

With DirectX and Metal being OS-specific, and AMD deciding to contribute its Mantle to the Khronos Group (think, Apple’s OpenCL contribution), the rapid emergence of Vulkan is smart and timely. The market needs a truly open standard and for explicit graphics, and Vulkan more than addresses the challenge.

 

Footnotes

1 – While a short history lesson on why OpenGL has essentially risen to dominance and plurality is beyond this article, part of the key advantage of OpenGL was that it gave companies like Sony, Nintendo and others a graphics API system for their non-Windows OS game systems. It also was the natural choice for mobile with smartphones and tablets, where Windows was never strong and still isn’t.

2 – Throughout this article we have used the term DirectX 12, which is actually the umbrella category of visual and audio technologies for Microsoft’s API standards. Direct3D 12 is the actual graphics API piece within the DirectX 12 family technologies.