Skip to main content

Khronos Blog

Fighting Fragmentation: Vulkan Portability Extension Released and Implementations Shipping

Over the last few years, providing the functionality of one graphics API by layering over another API has become increasingly popular. This post explores the value of layered implementations to the graphics community and provides details on a significant announcement from Khronos’ ongoing Vulkan® Portability™ initiative—the release of the provisional version of the Vulkan Portability extension with multiple shipping implementations! We will also take a look forward to the next steps for Vulkan Portability in our ongoing mission to bring Vulkan functionality everywhere it is needed—even on platforms where native drivers are not possible.

The Value of Layered Implementations

There are many active graphics API layering projects, some of which are shown in Figure 1. Most of these projects are in open source as many of them leverage, and contribute to, open source compiler frameworks such as Mesa. Many also rely on Khronos’ SPIR-V, an intermediate language with constructs for parallel computation and graphics, and its growing constellation of open source tools including SPIRV-Cross which disassembles SPIR-V into a variety of high-level shading languages.

Figure 1. Active Open Source Graphics API Layering Projects

Layered implementations fight industry fragmentation by enabling more applications to run on more platforms, even in a fragmented industry API landscape. For example, the first row in Figure 1. shows how Vulkan is being used as a porting target to bring additional APIs to platforms to enable more content without the need for additional kernel-level drivers. Layered API implementations have been used to successfully ship production applications on multiple platforms.

The columns in Figure 1. show layering projects being used to make APIs available across additional platforms, even if no native drivers are available, giving application developers the deployment flexibility they need to develop with the graphics API of their choice and ship across multiple platforms.

The first column in Figure 1. is our main topic. Enabling layered implementations of Vulkan functionality across diverse platforms is the goal of Khronos’ Vulkan Portability Initiative.

Vulkan Portability Initiative

The Khronos Vulkan Portability Initiative fights platform fragmentation by encouraging and enabling layered implementations of a Vulkan subset over Metal, DX12, and other APIs. Most early interest in Vulkan Portability has been in layering Vulkan functionality over Apple’s Metal API, as native Vulkan drivers are not permitted on macOS and iOS.

MoltenVK and gfx-portability are royalty-free, open-source projects that layer Vulkan functionality over Metal. Both use SPIRV-Cross to translate the application’s native Vulkan shaders into Metal Shading Language for compilation by the Apple-supplied Metal compiler and provide a run-time Vulkan to Metal API shim. To the platform, software using MoltenVK or gfx-portability appears as a standard Metal application.

Also, as part of the Vulkan Portability Initiative, LunarG has ported the open source Vulkan SDK to macOS, enabling developers to build, run, and debug their Vulkan applications on their macOS machines.

Figure 2. Vulkan Portability Bringing Vulkan Application to macOS and iOS

Layered implementations such as MoltenVK and gfx-portability can provide almost complete Vulkan functionality when running over other modern 3D APIs such as Metal. However, there are almost always some parts of Vulkan that cannot be supported at close-to-native performance speeds; and, which parts are missing depend on the underlying API, its version, and other platform constraints.

This means that developers relying on layered implementations of Vulkan functionality across multiple platforms and devices may find that different subsets of the Vulkan API are available at different times.

It is for this reason that the Vulkan Portability Initiative has been working hard to define the “VK_KHR_portability_subset” Vulkan Portability extension to provide standardized, cross-vendor queries for what Vulkan functionality is provided by layered implementations when running on a particular platform.

The big news today is that Khronos has shipped the provisional version of the Vulkan Portability Extension version 1.0 and it is shipping today in both MoltenVK and gfx-portability!

If you want to try out the extension, build MoltenVK or download gfx-portability-0.8.1 and redirect the Vulkan loader (e.g. by overriding VK_ICD_FILENAMES environment) to a JSON manifest using the regular ICD logic, as if MoltenVK and gfx-portability were native Vulkan drivers.

What’s Next for Vulkan Portability

We are proud of the level of detailed exploration and experimentation that has gone into defining the provisional Vulkan Portability Extension with only a dozen or so flags that are needed to indicate functionality that may be missing in layered Vulkan functionality. But our work is just beginning.

The Vulkan Portability Extension is being first released as a provisional specification to enable industry feedback before finalization. To streamline developer interactions, Khronos will finalize and iterate all future versions of the Vulkan Portability Extension on the public Khronos GitHub, inviting cooperation with the open source community and developers using the layered implementations, so that layering issues, solutions and needed additional flags can be quickly identified and refined.

All developers are encouraged to provide feedback on the extension and file any issues and suggestions on the Vulkan Portability GitHub.

Another important component of the Vulkan Portability Initiative is upgrading the Vulkan Conformance Test Suite to recognize when tests are being run over a layer so that tests for missing functionality will not cause failures, but all functionality reported to be present by the Vulkan Portability Extension is fully tested to be conformant. Vulkan Portability implementations that pass this partial conformance process cannot be Vulkan conformant, but they will be enabled to use the Vulkan Portability trademark and logo to indicate that present functionality has been tested. This conformance work is substantially underway and, when complete, will enable the release of the finalized Vulkan Portability Extension.

Finally, LunarG is developing Device Simulation and Validation layers for the Vulkan SDK so developers can correctly and precisely use the functionality of a Vulkan Portability implementation for a target device—on any development system. A Device Simulation (DevSim) layer enables Vulkan development on a highly capable development system by "simulating" a less-capable target Vulkan implementation through constraining the reported features and resources on the more-capable implementation. A DevSim layer exposing the Vulkan Portability extension will be included in an upcoming SDK release in early October from LunarG. The eventual aim is to accurately gather the exact functionality of Vulkan Portability implementations across multiple devices, and to reflect that data into the DevSim layer to, for example, enable a developer working on a Windows-based system to develop Vulkan code that will run correctly on an iPhone. Portability Extension validation layers for verifying that applications use the Vulkan API correctly are in development and will be released in a future SDK.

So, if you are a developer implementing or using layered Vulkan functionality please give us your feedback on the provisional Vulkan Portability Extension and help us enable Vulkan applications wherever they are needed!

Comments