11 myths about volcano | electronic design


What you will learn:

  • What is volcano?
  • Details on the safety-critical standard Vulkan SC.
  • What is the difference between Vulkan and the Vulkan SC variant?

March 1, 2022 was a pivotal day in the world of security systems: Khronos Group ratified the Vulkan SC API standard. “Commercial” Vulkan has been available for a while. It is used in a variety of graphics and computing applications to maximize the capabilities and performance of the underlying GPU architecture. It also provides a fast and efficient, open standards-based way to scale across different architectures.

However, the Safety Critical (SC) variant promises to provide safety system designers with the same vectors while providing a path for certification of 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 allows a design to be safety certified.

It is important to remember that the Vulkan SC specification was developed to enable application developers to write safety-critical and functionally safe software. However, this does not mean that every Vulkan SC implementation is automatically certifiable. The Vulkan SC implementation must be designed to meet the goals of software security standards such as ISO 26262 or DO-178C.

Additionally, replacing your existing GPU driver in a non-secure 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 should also be designed with functional safety in mind.

2. Vulkan needs thousands of lines of startup code before you can draw anything.

With Vulkan and Vulkan SC, you need to be very specific about what resources you want the GPU to use and how you want the GPU to perform the rendering. This means that a lot of “startup” code is required to set up the initial state and graphics/compute pipeline needed by an application.

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

After you have your starting code ready, the object rendering code can be as simple as OpenGL SC. As you advance your unified state, tie up the right resources and then make a single draw call. Overall, this allows an application to be more flexible and gives application developers the ability to customize their startup code to suit their specific application if needed.

3. Vulkan is a graphics API only.

The Vulkan standard allows an implementation to provide only computational functionality without providing graphics functionality. Therefore, vendors can implement a compliant Vulkan driver that can only run compute shaders.

The compute pipeline in Vulkan is quite powerful and can be used alone for applications that don’t have visualization needs. For applications that have visualization needs, the API allows for easy sharing of data between the compute and graphics parts of their pipeline.

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

  • Vulkan as a specification only grows and with each new iteration its computing capacities increase.
  • The Khronos Vulkan Machine Learning (ML) working group continues to propose Vulkan extensions that can support data-centric AI and ML solutions.
  • The Khronos group is investigating 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 leverage features available in popular frameworks such as TensorFlow and Caffe in parallel, using Vulkan SC as the computational acceleration layer.

5. You can’t have a pure Vulkan arithmetic 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. Most of the differences are within certain parameters of shared features, 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 that the application will require at runtime. This is important as Vulkan SC does not allow memory allocations to be freed to prevent fragmentation of memory resources. Allowing the application to specify the required resources ensures that the implementation does not run out of resources at runtime.

Aside from memory management, the biggest difference between SC and standard Vulkan is that pipeline compilation in Vulkan SC is done offline. This means that a Vulkan SC application compiles all shaders into Vulkan SC pipelines in an offline compilation process. Then, during runtime execution, the application can choose to load and bind a precompiled pipeline object.

The benefit of off-line compilation for SC software is that this code does not need to be certified for each target system where the Vulkan SC implementation is deployed, since the compiler/linker stages are not part of the runtime. There is also a well-defined and deterministic way to track the shader code running on the target device (e.g. GPU) since new/untested shader code cannot be compiled and launched at runtime.

7. Vulkan is designed for GPU programmers 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 the GPU is controlled.

In addition, Vulkan was designed to more easily abstract the GPU with a simpler interface. The APIs of earlier GPUs required the driver to implement complex constructs such as shader compilers. This means that drivers can easily have bugs and quirks when interpreting shader code, and creating compilers becomes a difficult problem. With Vulkan’s simplified approach to control, it’s easier for driver developers to remove bugs and quirks and have a consistent experience across different GPUs.

Finally, Vulkan was designed to allow for functional reuse. This allows more novice developers to 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 states of the offline pipeline, such as B. the number of render passes or the shaders used are specified at compile time. They offer some security benefits, such as B. Preventing unverified shaders and render passes from being loaded on the GPU. Other pipeline states, e.g. B. clear color, are accessible via the dynamic state control.

Extensions like “VK_EXT_extended_dynamic_state” give applications even more control over the offline pipeline, e.g. For example, the ability to control cull mode, viewport dimensions, scissor status, and more. This allows you to control all of the usual states in an offline pipeline, making it fairly configurable and flexible.

In addition, the commercial Vulkan supports “dynamic building” pipelines during the runtime of an application. However, this is a use case to avoid as it can be quite expensive to create pipelines at runtime of the application. Therefore, a well-designed Vulkan application should be able to transfer to offline pipelines with little impact.

9. Vulkan does not have wide acceptance.

Not true – commercial Vulkan is widely used throughout the industry, from game engine developers to content creator tools. Every major GPU vendor has a Vulkan implementation for their hardware. Therefore, application developers can be confident that their application will run on a variety of hardware when using Vulkan.

Vulkan SC has also begun to see widespread acceptance for safety-critical, functionally safe graphics and computing, with both Intel and Arm adopting the API as their standard platform for safe graphics and computing applications. Developers of safety-critical applications can be assured that the only safety-critical API capable of providing graphics and computational support will be available on a wide range of hardware.

10. Vulkan only works on modern, high-end, high-performance GPUs.

The Vulkan standard was designed to support many different hardware with different capabilities. Khronos himself has said that the standard will be supported by GPUs capable of running OpenGL ES 3.1. This standard was developed for low-end, low-power mobile GPUs that were developed eight or more years ago. In fact, Vulkan can be a better choice for lower-power, lower-performance 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 for the average application developer.

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

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


Comments are closed.