Today, Khronos® has released the final versions of the set of Vulkan®, GLSL and SPIR-V extension specifications that seamlessly integrate ray tracing into the existing Vulkan framework. This is a significant milestone as it is the industry’s first open, cross-vendor, cross-platform standard for ray tracing acceleration – and can be deployed either using existing GPU compute or dedicated ray tracing cores. Vulkan Ray Tracing will be familiar to anyone who has used DirectX Raytracing (DXR) in DirectX 12, but also introduces advanced functionality such as the ability to load balance ray tracing setup operations onto the host CPU. Although ray tracing will be first deployed on desktop systems, these Vulkan extensions have been designed to enable and encourage ray tracing to also be deployed on mobile.
These extensions were initially released as provisional versions in March 2020. Since that time (see Figure 1), we have received and incorporated feedback from hardware vendors and software developers, both inside Khronos and from the wider industry, but the overall shape of the API and the functionality provided are fundamentally unchanged. Thank you to all who reviewed and used the provisional extensions and especially those who provided feedback!
Today’s release of the extension specifications is just the start of the rollout of Vulkan Ray Tracing. Over the coming days and weeks, additional ecosystem components such as shader toolchains and validation layers will be updated with support for ray tracing functionality to ensure developers can easily use these extensions in their applications. Progress on these ecosystem updates can be tracked in GitHub. This will culminate with the release of the Vulkan SDK (1.2.162.0 or later) with Khronos Vulkan Ray Tracing support in mid-December.
This post will highlight the most important differences between the provisional and final versions of the Vulkan Ray Tracing extensions and explain some of the reasoning behind the changes.
Show Me the Specs!
The overall functionality provided by the set of Vulkan Ray Tracing extensions is unchanged since their provisional versions. The final set of extensions released today is:
- Vulkan extension specifications
- SPIR-V extensions specifications
- GLSL extensions specifications
Extension Structure
The most obvious change is that the provisional VK_KHR_ray_tracing extension has been split into 3 extensions:
VK_KHR_acceleration_structure
– for acceleration structure building and managementVK_KHR_ray_tracing_pipeline
– for ray tracing shader stages and pipelines, andVK_KHR_ray_query
– providing ray query intrinsics for all shader stages.
We received feedback that some markets desired the ability to support ray queries without ray pipelines, and the original extension was subdivided in order to avoid duplication and artificial dependencies. Implementers may choose to support either VK_KHR_ray_tracing_pipeline, VK_KHR_ray_query, or both, depending on market needs. Both of these extensions depend on the VK_KHR_acceleration_structure extension to provide a common base for acceleration structure management. The major desktop vendors remain committed to supporting ray pipelines and ray queries. For specifics of support for optional features and support in other markets, please talk to individual vendors.
The Vulkan Ray Tracing extensions are no longer marked as provisional and so the extension interfaces for the five extensions are now defined in the main vulkan_core.h header instead of the provisional vulkan_beta.h, and users no longer need to #define VK_ENABLE_BETA_EXTENSIONS to enable the Vulkan Ray Tracing functionality.
The dependencies for the extensions have also changed. Vulkan 1.1 and SPIR-V 1.4 are now required. VK_KHR_acceleration_structure requires Vulkan 1.1, VK_EXT_descriptor_indexing, VK_KHR_buffer_device_address, and VK_KHR_deferred_host_operations. We realize that a lengthy list of extension dependencies is annoying and ideally would have liked to simply require Vulkan 1.2, but not all platforms are shipping Vulkan 1.2 support at this time and we do not want to add any artificial barriers for adopting ray tracing functionality. Applications are able to just target Vulkan 1.2 directly for simplicity, if supported by all their target markets. We also considered not making VK_KHR_deferred_host_operations an explicit dependency, but changes to the pipeline creation with deferred operations required it to be kept. We made VK_KHR_pipeline_library a soft requirement for VK_KHR_ray_tracing_pipeline instead of a strict requirement, so applications only need to enable it if they are actually using it. In addition to VK_KHR_acceleration_structure, VK_KHR_ray_tracing_pipeline and VK_KHR_ray_query both require SPIR-V 1.4 at a minimum, due to changes in entry point requirements that were added in that version. SPIR-V 1.5 can also be used on Vulkan 1.2 implementations.
Featurewise, the following is mandated for all implementations.
VK_KHR_acceleration_structure requires:
VK_KHR_deferred_host_operations
accelerationStructure
,descriptorBindingAccelerationStructureUpdateAfterBind
,- all the features required by the
descriptorIndexing
feature (if Vulkan 1.2 is supported) or theVK_EXT_descriptor_indexing
extension, and bufferDeviceAddress
from Vulkan 1.2 or theVK_KHR_buffer_device_address
Implementations that support VK_KHR_ray_tracing_pipeline
require:
VK_KHR_acceleration_structure
,rayTracingPipeline
,rayTracingPipelineTraceRaysIndirect
,rayTraversalPrimitiveCulling
, ifVK_KHR_ray_query
is also supported, andVK_KHR_pipeline_library
.
Implementations that support VK_KHR_ray_query
require:
VK_KHR_acceleration_structure
, andrayQuery
.
Additionally there are a number of optional capabilities defined with the extensions.
For VK_KHR_acceleration_structure
these are:
accelerationStructureCaptureReplay
,accelerationStructureIndirectBuild
, andaccelerationStructureHostCommands
.
For VK_KHR_ray_tracing_pipeline
these are:
rayTracingPipelineShaderGroupHandleCaptureReplay
,rayTracingPipelineShaderGroupHandleCaptureReplayMixed
, andrayTraversalPrimitiveCulling
, ifVK_KHR_ray_query
is not supported.
For more information, visit here.