Home Critical engine 11 myths about Vulkan | Electronic design

11 myths about Vulkan | Electronic design

0

What you will learn:

  • What is Vulkan?
  • Details on Vulkan SC Security Critical Standard.
  • How do Vulkan and the Vulkan SC variant differ?

March 1, 2022 marked a pivotal day in the world of security systems: Khronos Group ratified the Vulkan SC API Standard. “Commercial” Vulkan has been available for some time. It is used in a wide range of graphics and compute applications to optimize the capabilities and performance of the underlying GPU architecture. It also provides a fast and efficient way, based on open standards, to evolve on various architectures.

However, the security-critical (SC) variant promises to bring those same vectors to security system developers while also providing a way to certify the software stack to meet various industry security 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 allows a design to be certified for safety.

It is important to keep in mind that the Vulkan SC specification was designed to enable application developers to write security-critical and functional software. However, this does not mean that any implementation of Vulkan SC is automatically certifiable. The implementation of Vulkan SC should be designed according to the objectives of software security standards such as ISO 26262 or DO-178C.

Additionally, replacing your existing GPU driver in an insecure system with Vulkan SC will not automatically make your entire platform functionally secure. Other system software such as RTOS, BSP, and application software must be functionally safe, and hardware must also be designed with functional safety.

2. Vulkan requires thousands of lines of startup code before it can draw anything.

Vulkan and Vulkan SC require you to be very explicit about what resources you want from the GPU and how you want the GPU to render. This means that a lot of “starter” code is involved to set up the initial state and the graphics/compute pipeline required by an application.

Most of this code can be extracted into a custom library specific to the type of applications you are building. Alternatively, you can use third-party libraries such as LunarG’s Vulkan framework from its tutorials or AMD’s Virtual Memory Allocator (VMA) to simplify resource allocation.

Once you’ve completed your starter 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 pull call. Overall, this allows an app to be more flexible and gives app developers the flexibility to tailor their starter code to their specific app if needed.

3. Vulkan is just a GUI API.

The Vulkan standard allows an implementation to expose only compute functionality without exposing graphics capabilities. This allows vendors to implement a compliant Vulkan driver capable of running compute shaders only.

Vulkan’s compute pipeline is quite powerful and can be used on its own for applications that have no visualization requirements. For applications that have visualization requirements, the API enables easy sharing of data between the compute and graph parts of their pipeline.

4. Vulkan Compute is not powerful enough and it is only meant to support graphics.

  • Vulkan, as a spec, is only growing, and with each new iteration, its computing capabilities increase.
  • The Khronos Vulkan Machine Learning (ML) working group continues to deliver Vulkan extensions capable of supporting compute-centric AI and ML solutions.
  • The Khronos group is exploring a security-critical version of the SYCL parallel programming API that will be compatible with Vulkan computing.
  • CoreAVI builds a robust AI/ML framework that can parallel capabilities available in well-known frameworks like TensorFlow and Caffe using Vulkan SC as a computational acceleration layer.

5. You cannot have a Vulkan compute-only implementation.

In fact, the spec says you can’t have a graphics-only implementation of Vulkan. However, you can certainly 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 in some common function settings, where Vulkan SC introduces additional structures that define things like resource usage.

These structures allow an application to provide the Vulkan SC implementation with a clear picture of the resources the application will need at runtime. This is important because Vulkan SC disallows freeing memory grants to prevent fragmentation of memory resources. Allowing the application to specify the resources it needs ensures that the implementation will not run out of resources at runtime.

Besides memory management, the biggest difference between SC and standard Vulkan is the pipeline compilation done offline in Vulkan SC. This means that a Vulkan SC application will compile all shaders in Vulkan SC pipelines in an offline compilation process. While the runtime is running, the application can then choose to load and bind a precompiled pipeline object.

The advantage of offline compilation for SC software is that since the compiler/linker steps are not part of the runtime, this code does not need to be certified for every target system on which the Vulkan SC implementation is deployed. There is also a well-defined and deterministic way to track which shader code will run in the target device (e.g. GPU), as new/untested shader code cannot be compiled and run at the time of execution.

7. Vulkan is designed for GPU programming experts only.

One of the design goals of the Vulkan specification was to make it more accessible, so that people unfamiliar with GPU programming could read the specification and understand how to control the GPU.

Additionally, Vulkan was designed to more easily abstract the GPU with a simpler interface. Previous GPU APIs required the driver to implement complex constructs such as shader compilers. This means that drivers could easily have bugs and quirks in the way they interpret shader code, and building compilers becomes a difficult problem. With Vulkan’s streamlined approach to control, it’s easier for driver developers to squash bugs and quirks and have a consistent experience across different GPUs.

Finally, Vulkan was designed to enable functional reuse. Therefore, more novice developers can use third-party libraries or pull their own code into libraries to simplify the development process.

8. Offline pipelines in Vulkan SC are less configurable and flexible than compiling online pipelines in Vulkan.

Some offline pipeline states, such as number of render passes or shaders used, are fixed at compile time. They provide some security benefits, such as preventing shaders from loading and unverified render passes on the GPU. Other pipeline states, for example a light color, can be accessed through the dynamic state command.

Extensions such as “VK_EXT_extended_dynamic_state” give applications even more control over the offline pipeline, such as the ability to control disposal mode, viewport dimensions, scissor state, and more. This lets you control all the usual states of an offline pipeline, making them quite configurable and flexible.

Additionally, commercial Vulkan supports “dynamic build” pipelines while an application is running. However, this is a use case to be avoided, as it can be quite expensive to build pipelines while the application is running. Therefore, a well-designed Vulkan application should be able to transfer to offline pipelines with little impact.

9. Vulkan does not have wide adoption.

That’s not true – commercial Vulkan is widely adopted across the industry, from game engine developers to content creation tools. Every major GPU vendor has a Vulkan implementation for their hardware. Thus, application developers can be sure that if they use Vulkan, their application will be able to run on a wide variety of hardware.

Vulkan SC also began to be widely adopted for mission-critical and functional graphics and computing, with Intel and Arm adopting the API as the standard platform for secure graphics and computing applications. Developers of security-critical applications can be confident that the only security-critical API capable of providing graphics and computing support will be available on a variety of hardware.

10. Vulkan only works on modern high-end and powerful GPUs.

The Vulkan standard was designed to support many different hardware with disparate capabilities. Khronos themselves said the standard would 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 may be a better choice for less powerful and less capable GPUs because the application developer has more control over the GPU and can choose the optimal execution path for this low-end hardware.

11. Vulkan is too low a level for the average app developer.

Vulkan gives app developers the ability to access the “lower tier” of the GPU if needed, but it was also designed with a “platform approach”. This means that developers can easily create abstract layers on top of Vulkan to simplify the application development process. These can range from comprehensive frameworks, to building Vulkan applications, to small libraries to make some aspect of using Vulkan easier. As a result, developers can take a high-level approach to speed up development and then more easily switch to low-level access when they need to improve performance.

An added benefit of Vulkan’s platform-level approach is that it allows developers to implement other APIs on top of Vulkan. For example, the “DXVK” project lets you build Direct-X apps on Vulkan, and CoreAVI’s VkCoreGL SC product lets you build OpenGL SC apps on Vulkan SC.