What you'll learn:
- What is Vulkan?
- Details on the Vulkan SC safety-critical standard.
- How much do Vulkan and the variant Vulkan SC differ?
March 1, 2022 marked a pivotal day in the world of safety systems: The Khronos Group ratified the Vulkan SC API standard. “Commercial” Vulkan has been available for some time. It’s used in a diverse array of both graphics and compute applications to maximize the capabilities and performance of the underlying GPU architecture. It also offers a quick and efficient, open standards-based means to scale across diverse architectures.
However, the safety-critical (SC) variant promises to bring those same vectors to developers of safety systems while also offering a path to certifying the software stack to meet various industry safety standards, such as ISO 26262 (automotive), IEC 61508 (industrial), and DO-178C (avionics). The following aims to dispel some of the common myths surrounding the Vulkan API standard.
1. Using Vulkan SC enables a design to be safety certified.
It’s important to keep in mind that the Vulkan SC specification has been designed to enable application developers to write safety-critical and functionally safe software. However, it doesn’t mean that any Vulkan SC implementation is automatically certifiable. The Vulkan SC implementation must be designed to the objectives of software safety standards like ISO 26262 or DO-178C.
In addition, replacing your existing GPU driver in a non-safe system with Vulkan SC will not automatically make your entire platform functionally safe. Other system software like the RTOS, BSP, and application software need to be functionally safe, and the hardware should be designed with functional safety as well.
2. Vulkan requires thousands of lines of startup code before you can draw anything.
Vulkan and Vulkan SC require you to be very explicit about the resources that you want from the GPU and how you would like the GPU to perform rendering. This means a lot of “startup” code is involved to set up the initial state and graphics/compute pipeline required by an application.
Most of this code can be abstracted out into a custom-made library specific to the type of applications you’re building. Alternately, you can use third-party libraries such as LunarG’s Vulkan framework from its tutorials or AMD’s Virtual Memory Allocator (VMA) to simplify the resource allocation.
After you’ve completed your startup code, the code to render objects can be as simple as OpenGL SC. When you push your uniform state, you bind the correct resources and then make a single draw call. Overall, this allows an application to be more flexible and gives application developers the option to tweak their startup code to their specific application if needed.
3. Vulkan is only a graphics API.
The Vulkan standard allows for an implementation to only expose compute functionality without exposing any graphics capabilities. Thus, vendors can implement a conformant Vulkan driver that’s able to only run compute shaders.
The compute pipeline in Vulkan is quite powerful and can be used on its own for applications that have no visualization requirements. For applications that do have visualization requirements, the API allows for easy sharing of data between the compute and graphics parts of their pipeline.
4. Vulkan Compute isn’t powerful enough, and it’s only meant to support graphics.
- Vulkan, as a specification, is only growing and with each new iteration its compute capabilities are increasing.
- The Khronos Vulkan Machine Learning (ML) working group continues to propose Vulkan extensions capable of supporting compute-centric AI and ML solutions.
- The Khronos group is exploring a safety-critical version of the parallel-programming API SYCL that will be compatible with Vulkan compute.
- CoreAVI is building a robust AI/ML framework that can parallel the capabilities available in well-known frameworks like TensorFlow and Caffe using Vulkan SC as the compute acceleration layer.
5. You can’t have a Vulkan compute-only implementation.
In fact, the specification says that you can’t have a graphics-only implementation of Vulkan. However, you certainly can have a compute-only implementation.
6. Vulkan and Vulkan SC are quite different.
Vulkan SC is very similar to Vulkan. The bulk of the differences exist within certain parameters of common functions, where Vulkan SC introduces additional structures that define things like resource utilization.
These structures enable an application to provide the Vulkan SC implementation with a clear picture of the resources that the application will need at runtime. This is important because Vulkan SC disallows freeing memory allocations to prevent fragmentation of the memory resources. Allowing the application to specify the resources it requires ensures that the implementation will not run out of resources at runtime.
Aside from memory management, the biggest difference between SC and standard Vulkan is pipeline compilation being performed offline in Vulkan SC. This means that a Vulkan SC application will compile all of the shaders into Vulkan SC pipelines in an offline compilation process. During runtime execution, the application then can select to load and bind a precompiled pipeline object.
The advantage of offline compilation for SC software is that since the compiler/linker stages aren’t part of the runtime, this code needn’t be certified for every target system where the Vulkan SC implementation is deployed. There’s also a well-defined and deterministic way to track the shader code that will execute in the target device (e.g., GPU), since new/untested shader code can’t be compiled and launched at runtime.
7. Vulkan is designed solely for GPU programming experts.
One of the design goals of the Vulkan specification was to make it more approachable, so that people unfamiliar with GPU programming would be able to read the specification and understand how to control the GPU.
Furthermore, Vulkan was designed to abstract the GPU more easily with a simpler interface. Previous GPUs’ APIs required the driver to implement complex constructs like shader compilers. This means that drivers could easily have bugs and quirks in how they interpret shader code, and building compilers becomes a difficult problem. With Vulkan’s simplified approach for control, it’s easier for driver developers to remove bugs and quirks and have a consistent experience across different GPUs.
Lastly Vulkan has been designed to allow for functional reuse. As a result, more novice developers can use third-party libraries, or abstract their own code into libraries to simplify the development process.
8. Offline pipelines in Vulkan SC are less configurable and flexible than online pipeline compilation in Vulkan.
Some offline pipeline states, such as the number of render passes or the shaders being used, are fixed at compile time. They provide some safety benefits such as preventing unverified shaders and render passes from being loaded onto the GPU. Other pipeline states, e.g., clear color, are accessible through the dynamic state control.
Extensions like “VK_EXT_extended_dynamic_state” give applications even more control over the offline pipeline, such as being able to control the cull mode, viewport dimensions, scissor state, and more. This enables you to control all of the usual state in an offline pipeline, making them quite configurable and flexible.
In addition, commercial Vulkan does support “dynamic building” pipelines during the runtime of an application. However, this is a use case to be avoided, as it can be quite expensive to build pipelines during the application’s runtime. Therefore, a well-designed Vulkan application should be able to transfer over to offline pipelines with little impact.
9. Vulkan doesn’t have wide adoption.
Not true—commercial Vulkan is widely adopted throughout the industry, from game-engine developers to content creator tools. Every major GPU vendor has a Vulkan implementation for its hardware. Thus, application developers can trust that if they use Vulkan, their application will be able to run on a wide variety of hardware.
Vulkan SC also has started to gain wide adoption for safety-critical, functionally safe graphics and compute, with both Intel and Arm adopting the API as their standard platform for safe graphics and compute applications. Safety-critical application developers can feel confident that the only safety-critical API capable of providing graphics and compute support will be available on a variety of hardware.
10. Vulkan only works on high-end, high-power, modern GPUs.
The Vulkan standard was designed to support lots of different hardware with disparate capabilities. Khronos themselves have said that the standard will be supported by GPUs that can run OpenGL ES 3.1. This standard was designed for low-end, low-power mobile GPUs that were designed eight or more years ago. In fact, Vulkan can be a better choice for lower-power, lower-performance GPUs as the application developer has more control over the GPU and can choose the optimal execution path for that low-end hardware.
11. Vulkan is too low level for the average application developer.
Vulkan gives application developers the ability to access the “lower level” of the GPU if needed, but it’s also been designed with a “platform approach.” This means that developers can easily build abstract layers on top of Vulkan to simplify the application development process. These can vary from complete frameworks to building Vulkan applications, to small libraries to make one aspect of using Vulkan easier. Consequently, developers can take a high-level approach for speed of development and then more easily move to low-level access when they need to improve performance.
One additional benefit of Vulkan’s platform-level approach is that it enables developers to implement other APIs on top of Vulkan. For example, the “DXVK” project allows you to build Direct-X applications on top of Vulkan, and the VkCoreGL SC product from CoreAVI makes it possible to build OpenGL SC applications on top of Vulkan SC.