Ray Tracing
Ray tracing uses a separate rendering pipeline from both the graphics and compute pipelines (see Ray Tracing Pipeline).
Within the ray tracing pipeline, a pipeline trace ray instruction can be called to perform a ray traversal that invokes the various ray tracing shader stages during its
execution.
The relationship between the ray tracing pipeline object and the geometries
present in the acceleration structure traversed is passed into the ray
tracing command in a VkBuffer object known as a shader binding
table.
OpExecuteCallableKHR can also be used in ray tracing pipelines to
invoke a callable shader.
During execution, control alternates between scheduling and other operations. The scheduling functionality is implementation-specific and is responsible for workload execution. The shader stages are programmable. Traversal, which refers to the process of traversing acceleration structures to find potential intersections of rays with geometry, is fixed function.
The programmable portions of the pipeline are exposed in a single-ray
programming model, with each invocation handling one ray at a time.
Memory operations can be synchronized using standard memory barriers.
The Workgroup scope and variables with a storage class of
Workgroup must not be used in the ray tracing pipeline.
Shader Call Instructions
A shader call is an instruction which may cause execution to continue elsewhere by creating one or more invocations that execute a different shader stage.
The following table lists all shader call instructions and which stages each one can directly call.
| Instruction | Intersection | Any-Hit | Closest Hit | Miss | Callable |
|---|---|---|---|---|---|
|
X |
X |
X |
X |
|
|
X |
X |
X |
X |
|
|
X |
||||
|
X |
||||
|
X |
X |
|||
|
X |
X |
|||
|
X |
X |
The invocations created by shader call instructions are grouped into subgroups by the implementation. Those subgroups may be unrelated to the subgroup of the parent invocation.
Pipeline trace ray instructions can be used recursively; invoked shaders
can themselves execute pipeline trace ray instructions, to a maximum depth
defined by the
maxRecursionDepth or
maxRayRecursionDepth limit.
Shaders directly invoked from the API always have a recursion depth of 0;
each shader executed by a pipeline trace ray instruction has a recursion
depth one higher than the recursion depth of the shader which invoked it.
Applications must not invoke a shader with a recursion depth greater than
the value of
maxRecursionDepth or
maxPipelineRayRecursionDepth specified in the pipeline.
There is no explicit recursion limit for other shader call instructions
which may recurse (e.g. OpExecuteCallableKHR) but there is an upper
bound determined by the stack size.
An invocation repack instruction is a ray tracing instruction where the
implementation may change the set of invocations that are executing.
When a repack instruction is encountered, the invocation is suspended and a
new invocation begins and executes the instruction.
After executing the repack instruction (which may result in other ray
tracing shader stages executing) the new invocation ends and the original
invocation is resumed, but it may be resumed in a different subgroup or at
a different SubgroupLocalInvocationId within the same subgroup.
When a subset of invocations in a subgroup execute the invocation repack
instruction, those that do not execute it remain in the same subgroup at the
same SubgroupLocalInvocationId.
The OpTraceRayKHR,
OpTraceRayMotionNV,
OpReorderThreadWithHintNV, OpReorderThreadWithHitObjectNV,
OpReportIntersectionKHR, and OpExecuteCallableKHR instructions are
invocation repack instructions.
The invocations that are executing before a shader call instruction, after the instruction, or are created by the instruction, are shader-call-related.
If the implementation changes the composition of subgroups, the values of
SubgroupSize, SubgroupLocalInvocationId,
SMIDNV, WarpIDNV,
and builtin variables that are derived from them (SubgroupEqMask,
SubgroupGeMask, SubgroupGtMask, SubgroupLeMask,
SubgroupLtMask) must be changed accordingly by the invocation repack
instruction.
The application must use Volatile semantics on these BuiltIn variables when used in the ray generation,
closest hit, miss, intersection, and callable shaders.
Similarly, the application must use Volatile semantics on any
RayTmaxKHR decorated Builtin used in an intersection shader.
|
Subgroup operations are permitted in the programmable ray tracing shader stages. However, shader call instructions place a bound on where results of subgroup instructions or subgroup-scoped instructions that execute the dynamic instance of that instruction are potentially valid. For example, care must be taken when using the result of a ballot operation that was computed before an invocation repack instruction, after that repack instruction. The ballot may be incorrect as the set of invocations could have changed. While the For clock operations, the value of a |
When a ray tracing shader executes a dynamic instance of an invocation repack instruction which results in another ray tracing shader being invoked, their instructions are related by shader-call-order.
For ray tracing invocations that are shader-call-related:
-
memory operations on
StorageBuffer,Image, andShaderRecordBufferKHRstorage classes can be synchronized using theShaderCallKHRscope. -
the
CallableDataKHR,IncomingCallableDataKHR,RayPayloadKHR,HitAttributeKHR, andIncomingRayPayloadKHRstorage classes are system-synchronized and no application availability and visibility operations are required. -
memory operations within a single invocation before and after the shader call instruction are ordered by program-order and do not require explicit synchronization.
Ray Tracing Commands
Ray tracing commands provoke work in the ray tracing pipeline. Ray tracing commands are recorded into a command buffer and when executed by a queue will produce work that executes according to the currently bound ray tracing pipeline. A ray tracing pipeline must be bound to a command buffer before any ray tracing commands are recorded in that command buffer.
To dispatch ray tracing use:
// Provided by VK_NV_ray_tracing
void vkCmdTraceRaysNV(
VkCommandBuffer commandBuffer,
VkBuffer raygenShaderBindingTableBuffer,
VkDeviceSize raygenShaderBindingOffset,
VkBuffer missShaderBindingTableBuffer,
VkDeviceSize missShaderBindingOffset,
VkDeviceSize missShaderBindingStride,
VkBuffer hitShaderBindingTableBuffer,
VkDeviceSize hitShaderBindingOffset,
VkDeviceSize hitShaderBindingStride,
VkBuffer callableShaderBindingTableBuffer,
VkDeviceSize callableShaderBindingOffset,
VkDeviceSize callableShaderBindingStride,
uint32_t width,
uint32_t height,
uint32_t depth);-
commandBufferis the command buffer into which the command will be recorded. -
raygenShaderBindingTableBufferis the buffer object that holds the shader binding table data for the ray generation shader stage. -
raygenShaderBindingOffsetis the offset in bytes (relative toraygenShaderBindingTableBuffer) of the ray generation shader being used for the trace. -
missShaderBindingTableBufferis the buffer object that holds the shader binding table data for the miss shader stage. -
missShaderBindingOffsetis the offset in bytes (relative tomissShaderBindingTableBuffer) of the miss shader being used for the trace. -
missShaderBindingStrideis the size in bytes of each shader binding table record inmissShaderBindingTableBuffer. -
hitShaderBindingTableBufferis the buffer object that holds the shader binding table data for the hit shader stages. -
hitShaderBindingOffsetis the offset in bytes (relative tohitShaderBindingTableBuffer) of the hit shader group being used for the trace. -
hitShaderBindingStrideis the size in bytes of each shader binding table record inhitShaderBindingTableBuffer. -
callableShaderBindingTableBufferis the buffer object that holds the shader binding table data for the callable shader stage. -
callableShaderBindingOffsetis the offset in bytes (relative tocallableShaderBindingTableBuffer) of the callable shader being used for the trace. -
callableShaderBindingStrideis the size in bytes of each shader binding table record incallableShaderBindingTableBuffer. -
widthis the width of the ray trace query dimensions. -
heightis height of the ray trace query dimensions. -
depthis depth of the ray trace query dimensions.
When the command is executed, a ray generation group of width
× height × depth rays is assembled.
To dispatch ray tracing use:
// Provided by VK_KHR_ray_tracing_pipeline
void vkCmdTraceRaysKHR(
VkCommandBuffer commandBuffer,
const VkStridedDeviceAddressRegionKHR* pRaygenShaderBindingTable,
const VkStridedDeviceAddressRegionKHR* pMissShaderBindingTable,
const VkStridedDeviceAddressRegionKHR* pHitShaderBindingTable,
const VkStridedDeviceAddressRegionKHR* pCallableShaderBindingTable,
uint32_t width,
uint32_t height,
uint32_t depth);-
commandBufferis the command buffer into which the command will be recorded. -
pRaygenShaderBindingTableis a VkStridedDeviceAddressRegionKHR that holds the shader binding table data for the ray generation shader stage. -
pMissShaderBindingTableis a VkStridedDeviceAddressRegionKHR that holds the shader binding table data for the miss shader stage. -
pHitShaderBindingTableis a VkStridedDeviceAddressRegionKHR that holds the shader binding table data for the hit shader stage. -
pCallableShaderBindingTableis a VkStridedDeviceAddressRegionKHR that holds the shader binding table data for the callable shader stage. -
widthis the width of the ray trace query dimensions. -
heightis height of the ray trace query dimensions. -
depthis depth of the ray trace query dimensions.
When the command is executed, a ray generation group of width
× height × depth rays is assembled.
When invocation mask image usage is enabled in the bound ray tracing pipeline, the pipeline uses an invocation mask image specified by the command:
// Provided by VK_HUAWEI_invocation_mask
void vkCmdBindInvocationMaskHUAWEI(
VkCommandBuffer commandBuffer,
VkImageView imageView,
VkImageLayout imageLayout);-
commandBufferis the command buffer into which the command will be recorded -
imageViewis an image view handle specifying the invocation mask imageimageViewmay be VK_NULL_HANDLE, which is equivalent to specifying a view of an image filled with ones value. -
imageLayoutis the layout that the image subresources accessible fromimageViewwill be in when the invocation mask image is accessed
To dispatch ray tracing, with some parameters sourced on the device, use:
// Provided by VK_KHR_ray_tracing_pipeline
void vkCmdTraceRaysIndirectKHR(
VkCommandBuffer commandBuffer,
const VkStridedDeviceAddressRegionKHR* pRaygenShaderBindingTable,
const VkStridedDeviceAddressRegionKHR* pMissShaderBindingTable,
const VkStridedDeviceAddressRegionKHR* pHitShaderBindingTable,
const VkStridedDeviceAddressRegionKHR* pCallableShaderBindingTable,
VkDeviceAddress indirectDeviceAddress);-
commandBufferis the command buffer into which the command will be recorded. -
pRaygenShaderBindingTableis a VkStridedDeviceAddressRegionKHR that holds the shader binding table data for the ray generation shader stage. -
pMissShaderBindingTableis a VkStridedDeviceAddressRegionKHR that holds the shader binding table data for the miss shader stage. -
pHitShaderBindingTableis a VkStridedDeviceAddressRegionKHR that holds the shader binding table data for the hit shader stage. -
pCallableShaderBindingTableis a VkStridedDeviceAddressRegionKHR that holds the shader binding table data for the callable shader stage. -
indirectDeviceAddressis a buffer device address which is a pointer to a VkTraceRaysIndirectCommandKHR structure containing the trace ray parameters.
vkCmdTraceRaysIndirectKHR behaves similarly to vkCmdTraceRaysKHR
except that the ray trace query dimensions are read by the device from
indirectDeviceAddress during execution.
The VkTraceRaysIndirectCommandKHR structure is defined as:
// Provided by VK_KHR_ray_tracing_pipeline
typedef struct VkTraceRaysIndirectCommandKHR {
uint32_t width;
uint32_t height;
uint32_t depth;
} VkTraceRaysIndirectCommandKHR;-
widthis the width of the ray trace query dimensions. -
heightis height of the ray trace query dimensions. -
depthis depth of the ray trace query dimensions.
The members of VkTraceRaysIndirectCommandKHR have the same meaning as
the similarly named parameters of vkCmdTraceRaysKHR.
To dispatch ray tracing, with some parameters sourced on the device, use:
// Provided by VK_KHR_ray_tracing_maintenance1 with VK_KHR_ray_tracing_pipeline
void vkCmdTraceRaysIndirect2KHR(
VkCommandBuffer commandBuffer,
VkDeviceAddress indirectDeviceAddress);-
commandBufferis the command buffer into which the command will be recorded. -
indirectDeviceAddressis a buffer device address which is a pointer to a VkTraceRaysIndirectCommand2KHR structure containing the trace ray parameters.
vkCmdTraceRaysIndirect2KHR behaves similarly to
vkCmdTraceRaysIndirectKHR except that shader binding table parameters
as well as dispatch dimensions are read by the device from
indirectDeviceAddress during execution.
The VkTraceRaysIndirectCommand2KHR structure is defined as:
// Provided by VK_KHR_ray_tracing_maintenance1 with VK_KHR_ray_tracing_pipeline
typedef struct VkTraceRaysIndirectCommand2KHR {
VkDeviceAddress raygenShaderRecordAddress;
VkDeviceSize raygenShaderRecordSize;
VkDeviceAddress missShaderBindingTableAddress;
VkDeviceSize missShaderBindingTableSize;
VkDeviceSize missShaderBindingTableStride;
VkDeviceAddress hitShaderBindingTableAddress;
VkDeviceSize hitShaderBindingTableSize;
VkDeviceSize hitShaderBindingTableStride;
VkDeviceAddress callableShaderBindingTableAddress;
VkDeviceSize callableShaderBindingTableSize;
VkDeviceSize callableShaderBindingTableStride;
uint32_t width;
uint32_t height;
uint32_t depth;
} VkTraceRaysIndirectCommand2KHR;-
raygenShaderRecordAddressis aVkDeviceAddressof the ray generation shader binding table record used by this command. -
raygenShaderRecordSizeis aVkDeviceSizenumber of bytes corresponding to the ray generation shader binding table record at base addressraygenShaderRecordAddress. -
missShaderBindingTableAddressis aVkDeviceAddressof the first record in the miss shader binding table used by this command. -
missShaderBindingTableSizeis aVkDeviceSizenumber of bytes corresponding to the total size of the miss shader binding table atmissShaderBindingTableAddressthat may be accessed by this command. -
missShaderBindingTableStrideis aVkDeviceSizenumber of bytes between records of the miss shader binding table. -
hitShaderBindingTableAddressis aVkDeviceAddressof the first record in the hit shader binding table used by this command. -
hitShaderBindingTableSizeis aVkDeviceSizenumber of bytes corresponding to the total size of the hit shader binding table athitShaderBindingTableAddressthat may be accessed by this command. -
hitShaderBindingTableStrideis aVkDeviceSizenumber of bytes between records of the hit shader binding table. -
callableShaderBindingTableAddressis aVkDeviceAddressof the first record in the callable shader binding table used by this command. -
callableShaderBindingTableSizeis aVkDeviceSizenumber of bytes corresponding to the total size of the callable shader binding table atcallableShaderBindingTableAddressthat may be accessed by this command. -
callableShaderBindingTableStrideis aVkDeviceSizenumber of bytes between records of the callable shader binding table. -
widthis the width of the ray trace query dimensions. -
heightis height of the ray trace query dimensions. -
depthis depth of the ray trace query dimensions.
The members of VkTraceRaysIndirectCommand2KHR have the same meaning as
the similarly named parameters of vkCmdTraceRaysKHR.
Indirect shader binding table buffer parameters must satisfy the same memory alignment and binding requirements as their counterparts in vkCmdTraceRaysIndirectKHR and vkCmdTraceRaysKHR.
Shader Binding Table
A shader binding table is a resource which establishes the relationship between the ray tracing pipeline and the acceleration structures that were built for the ray tracing pipeline. It indicates the shaders that operate on each geometry in an acceleration structure. In addition, it contains the resources accessed by each shader, including indices of textures, buffer device addresses, and constants. The application allocates and manages shader binding tables as VkBuffer objects.
Each entry in the shader binding table consists of
shaderGroupHandleSize bytes of data, either as queried by
vkGetRayTracingShaderGroupHandlesKHR to refer to those specified
shaders, or all zeros to refer to a zero shader group.
A zero shader group behaves as though it is a shader group consisting
entirely of VK_SHADER_UNUSED_KHR.
The remainder of the data specified by the stride is application-visible
data that can be referenced by a ShaderRecordBufferKHR block in the
shader.
The shader binding tables to use in a ray tracing pipeline are passed to the vkCmdTraceRaysNV , vkCmdTraceRaysKHR, or vkCmdTraceRaysIndirectKHR commands. Shader binding tables are read-only in shaders that are executing on the ray tracing pipeline.
Shader variables identified with the ShaderRecordBufferKHR storage
class are used to access the provided shader binding table.
Such variables must be:
-
typed as
OpTypeStruct, or an array of this type, -
identified with a
Blockdecoration, and -
laid out explicitly using the
Offset,ArrayStride, andMatrixStridedecorations as specified in Offset and Stride Assignment.
The Offset decoration for any member of a Block-decorated variable
in the ShaderRecordBufferKHR storage class must not cause the space
required for that variable to extend outside the range [0,
maxStorageBufferRange).
Accesses to the shader binding table from ray tracing pipelines must be
synchronized with the
VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_KHR
pipeline stage and an
access type of
VK_ACCESS_SHADER_READ_BIT.
|
Because different shader record buffers can be associated with the same
shader, a shader variable with |
Indexing Rules
In order to execute the correct shaders and access the correct resources during a ray tracing dispatch, the implementation must be able to locate shader binding table entries at various stages of execution. This is accomplished by defining a set of indexing rules that compute shader binding table record positions relative to the buffer’s base address in memory. The application must organize the contents of the shader binding table’s memory in a way that application of the indexing rules will lead to correct records.
Ray Generation Shaders
Only one ray generation shader is executed per ray tracing dispatch.
For vkCmdTraceRaysKHR, the location of the ray generation shader is
specified by the pRaygenShaderBindingTable->deviceAddress parameter — there is no indexing.
All data accessed must be less than pRaygenShaderBindingTable->size
bytes from deviceAddress.
pRaygenShaderBindingTable->stride is unused, and must be equal to
pRaygenShaderBindingTable->size.
For vkCmdTraceRaysNV, the location of the ray generation shader is
specified by the raygenShaderBindingTableBuffer and
raygenShaderBindingOffset parameters — there is no indexing.
Hit Shaders
The base for the computation of intersection, any-hit, and closest hit
shader locations is the instanceShaderBindingTableRecordOffset value
stored with each instance of a top-level acceleration structure
(VkAccelerationStructureInstanceKHR).
This value determines the beginning of the shader binding table records for
a given instance.
In the following rule, geometryIndex refers to the
geometry index of the intersected
geometry within the instance.
The sbtRecordOffset and sbtRecordStride values are passed in as
parameters to
traceNV()
or
traceRayEXT()
calls made in the shaders.
See Section 8.19 (Ray Tracing Functions) of the OpenGL Shading Language
Specification for more details.
In SPIR-V, these correspond to the SBTOffset and SBTStride
parameters to the pipeline trace ray
instructions.
The result of this computation is then added to
pHitShaderBindingTable->deviceAddress, a device address passed to
vkCmdTraceRaysKHR
, or
hitShaderBindingOffset, a base offset passed to vkCmdTraceRaysNV
.
For vkCmdTraceRaysKHR, the complete rule to compute a hit shader
binding table record address in the pHitShaderBindingTable is:
-
pHitShaderBindingTable->deviceAddress+pHitShaderBindingTable->stride× (instanceShaderBindingTableRecordOffset+geometryIndex×sbtRecordStride+sbtRecordOffset)
All data accessed must be less than pHitShaderBindingTable->size
bytes from the base address.
For vkCmdTraceRaysNV, the offset and stride come from direct
parameters, so the full rule to compute a hit shader binding table record
address in the hitShaderBindingTableBuffer is:
-
hitShaderBindingOffset+hitShaderBindingStride× (instanceShaderBindingTableRecordOffset+geometryIndex×sbtRecordStride+sbtRecordOffset)
Miss Shaders
A miss shader is executed whenever a ray query fails to find an intersection for the given scene geometry. Multiple miss shaders may be executed throughout a ray tracing dispatch.
The base for the computation of miss shader locations is
pMissShaderBindingTable->deviceAddress, a device address passed into
vkCmdTraceRaysKHR
, or
missShaderBindingOffset, a base offset passed into
vkCmdTraceRaysNV
.
The missIndex value is passed in as a parameter to
traceNV()
or
traceRayEXT()
calls made in the shaders.
See Section 8.19 (Ray Tracing Functions) of the OpenGL Shading Language
Specification for more details.
In SPIR-V, this corresponds to the MissIndex parameter to the
pipeline trace ray instructions.
For vkCmdTraceRaysKHR, the complete rule to compute a miss shader
binding table record address in the pMissShaderBindingTable is:
-
pMissShaderBindingTable->deviceAddress+pMissShaderBindingTable->stride×missIndex
All data accessed must be less than pMissShaderBindingTable->size
bytes from the base address.
For vkCmdTraceRaysNV, the offset and stride come from direct
parameters, so the full rule to compute a miss shader binding table record
address in the missShaderBindingTableBuffer is:
-
missShaderBindingOffset+missShaderBindingStride×missIndex
Callable Shaders
A callable shader is executed when requested by a ray tracing shader. Multiple callable shaders may be executed throughout a ray tracing dispatch.
The base for the computation of callable shader locations is
pCallableShaderBindingTable->deviceAddress, a device address passed
into vkCmdTraceRaysKHR
, or
callableShaderBindingOffset, a base offset passed into
vkCmdTraceRaysNV
.
The sbtRecordIndex value is passed in as a parameter to
executeCallableNV()
or
executeCallableEXT()
calls made in the shaders.
See Section 8.19 (Ray Tracing Functions) of the OpenGL Shading Language
Specification for more details.
In SPIR-V, this corresponds to the SBTIndex parameter to the
OpExecuteCallableNV
or
OpExecuteCallableKHR
instruction.
For vkCmdTraceRaysKHR, the complete rule to compute a callable shader
binding table record address in the pCallableShaderBindingTable is:
-
pCallableShaderBindingTable->deviceAddress+pCallableShaderBindingTable->stride×sbtRecordIndex
All data accessed must be less than pCallableShaderBindingTable->size
bytes from the base address.
For vkCmdTraceRaysNV, the offset and stride come from direct
parameters, so the full rule to compute a callable shader binding table
record address in the callableShaderBindingTableBuffer is:
-
callableShaderBindingOffset+callableShaderBindingStride×sbtRecordIndex
Ray Tracing Pipeline Stack
Ray tracing pipelines have a potentially large set of shaders which may be invoked in various call chain combinations to perform ray tracing. To store parameters for a given shader execution, an implementation may use a stack of data in memory. This stack must be sized to the sum of the stack sizes of all shaders in any call chain executed by the application.
If the stack size is not set explicitly, the stack size for a pipeline is:
-
rayGenStackMax + min(1,
maxPipelineRayRecursionDepth) × max(closestHitStackMax, missStackMax, intersectionStackMax + anyHitStackMax) + max(0,maxPipelineRayRecursionDepth-1) × max(closestHitStackMax, missStackMax) + 2 × callableStackMax
where rayGenStackMax, closestHitStackMax, missStackMax, anyHitStackMax, intersectionStackMax, and callableStackMax are the maximum stack values queried by the respective shader stages for any shaders in any shader groups defined by the pipeline.
This stack size is potentially significant, so an application may want to provide a more accurate stack size after pipeline compilation. The value that the application provides is the maximum value of the sum of all shaders in a call chain across all possible call chains, taking into account any application specific knowledge about the properties of the call chains.
|
For example, if an application has two types of closest hit and miss shaders that it can use but the first level of rays will only use the first kind (possibly reflection) and the second level will only use the second kind (occlusion or shadow ray, for example) then the application can compute the stack size by something similar to:
This is guaranteed to be no larger than the default stack size computation which assumes that both call levels may be the larger of the two. |
Ray Tracing Capture Replay
In a similar way to
bufferDeviceAddressCaptureReplay,
the rayTracingPipelineShaderGroupHandleCaptureReplay feature allows the
querying of opaque data which can be used in a future replay.
During the capture phase, capture/replay tools are expected to query opaque data for shader group handle replay using vkGetRayTracingCaptureReplayShaderGroupHandlesKHR.
Providing the opaque data during replay, using
VkRayTracingShaderGroupCreateInfoKHR::pShaderGroupCaptureReplayHandle
at pipeline creation time, causes the implementation to generate identical
shader group handles to those in the capture phase, allowing capture/replay
tools to reuse previously recorded shader binding table buffer contents or
to obtain the same handles by calling
vkGetRayTracingCaptureReplayShaderGroupHandlesKHR again.
Ray Tracing Validation
Ray tracing validation can help root cause application issues and improve performance. Unlike existing validation layers, ray tracing validation performs checks at an implementation level, which helps identify potential problems that may not be caught by the layer.
By enabling the ray tracing validation feature, warnings and errors can be delivered straight from a ray tracing implementation to the application through a messenger callback registered with the implementation, where they can be processed through existing application-side debugging or logging systems.