HORIZON HASKELLDocslts/ghc-9.14.x3e2d5682026-10-11Search names, modules, packages, or :: a typeCtrl K

GHC 9.14.1 · lts/ghc-9.14.x · 3e2d568 · 2026-10-11

Modulevulkan-3.27GHC2021

Vulkan.Extensions.VK_KHR_acceleration_structure

Name

VK_KHR_acceleration_structure - device extension

VK_KHR_acceleration_structure

Name String

VK_KHR_acceleration_structure

Extension Type

Device extension

Registered Extension Number

151

Revision

13

Ratification Status

Ratified

Extension and Version Dependencies

Vulkan Version 1.1          and

VK_EXT_descriptor_indexing          and

VK_KHR_buffer_device_address      or

Vulkan Version 1.2 and VK_KHR_deferred_host_operations

API Interactions
  • Interacts with VK_VERSION_1_2

  • Interacts with VK_VERSION_1_3

  • Interacts with VK_EXT_debug_report

  • Interacts with VK_KHR_format_feature_flags2

Contact

Other Extension Metadata

Last Modified Date

2021-09-30

Contributors
  • Samuel Bourasseau, Adobe

  • Matthäus Chajdas, AMD

  • Greg Grebe, AMD

  • Nicolai Hähnle, AMD

  • Tobias Hector, AMD

  • Dave Oldcorn, AMD

  • Skyler Saleh, AMD

  • Mathieu Robart, Arm

  • Marius Bjorge, Arm

  • Tom Olson, Arm

  • Sebastian Tafuri, EA

  • Henrik Rydgard, Embark

  • Juan Cañada, Epic Games

  • Patrick Kelly, Epic Games

  • Yuriy O’Donnell, Epic Games

  • Michael Doggett, Facebook/Oculus

  • Ricardo Garcia, Igalia

  • Andrew Garrard, Imagination

  • Don Scorgie, Imagination

  • Dae Kim, Imagination

  • Joshua Barczak, Intel

  • Slawek Grajewski, Intel

  • Jeff Bolz, NVIDIA

  • Pascal Gautron, NVIDIA

  • Daniel Koch, NVIDIA

  • Christoph Kubisch, NVIDIA

  • Ashwin Lele, NVIDIA

  • Robert Stepinski, NVIDIA

  • Martin Stich, NVIDIA

  • Nuno Subtil, NVIDIA

  • Eric Werness, NVIDIA

  • Jon Leech, Khronos

  • Jeroen van Schijndel, OTOY

  • Juul Joosten, OTOY

  • Alex Bourd, Qualcomm

  • Roman Larionov, Qualcomm

  • David McAllister, Qualcomm

  • Lewis Gordon, Samsung

  • Ralph Potter, Samsung

  • Jasper Bekkers, Traverse Research

  • Jesse Barker, Unity

  • Baldur Karlsson, Valve

Description

In order to be efficient, rendering techniques such as ray tracing need a quick way to identify which primitives may be intersected by a ray traversing the geometries. Acceleration structures are the most common way to represent the geometry spatially sorted, in order to quickly identify such potential intersections.

This extension adds new functionalities:

  • Acceleration structure objects and build commands

  • Structures to describe geometry inputs to acceleration structure builds

  • Acceleration structure copy commands

New Object Types

New Commands

New Structures

New Unions

New Enums

New Bitmasks

New Enum Constants

If VK_EXT_debug_report is supported:

If VK_KHR_format_feature_flags2 or Vulkan Version 1.3 is supported:

Issues

  1. How does this extension differ from VK_NV_ray_tracing?

DISCUSSION:

The following is a summary of the main functional differences between VK_KHR_acceleration_structure and VK_NV_ray_tracing:

  1. Can you give a more detailed comparison of differences and similarities between VK_NV_ray_tracing and VK_KHR_acceleration_structure?

DISCUSSION:

The following is a more detailed comparison of which commands, structures, and enums are aliased, changed, or removed.

  1. What are the changes between the public provisional (VK_KHR_ray_tracing v8) release and the internal provisional (VK_KHR_ray_tracing v9) release?

  1. What are the changes between the internal provisional (VK_KHR_ray_tracing v9) release and the final (VK_KHR_acceleration_structure v11) release?

  1. What is ACCELERATION_STRUCTURE_TYPE_GENERIC_KHR for?

RESOLVED: It is primarily intended for API layering. In DXR, the acceleration structure is basically just a buffer in a special layout, and you do not know at creation time whether it will be used as a top or bottom level acceleration structure. We thus added a generic acceleration structure type whose type is unknown at creation time, but is specified at build time instead. Applications which are written directly for Vulkan should not use it.

Version History

  • Revision 1, 2019-12-05 (Members of the Vulkan Ray Tracing TSG)

    • Internal revisions (forked from VK_NV_ray_tracing)

  • Revision 2, 2019-12-20 (Daniel Koch, Eric Werness)

    • Add const version of DeviceOrHostAddress (!3515)

    • Add VU to clarify that only handles in the current pipeline are valid (!3518)

    • Restore some missing VUs and add in-place update language (#1902, !3522)

    • rename VkAccelerationStructureInstanceKHR member from accelerationStructure to accelerationStructureReference to better match its type (!3523)

    • Allow VK_ERROR_INVALID_OPAQUE_CAPTURE_ADDRESS for pipeline creation if shader group handles cannot be reused (!3523)

    • update documentation for the VK_ERROR_INVALID_OPAQUE_CAPTURE_ADDRESS error code and add missing documentation for new return codes from VK_KHR_deferred_host_operations (!3523)

    • list new query types for VK_KHR_ray_tracing (!3523)

    • Fix VU statements for VkAccelerationStructureGeometryKHR referring to correct union members and update to use more current wording (!3523)

  • Revision 3, 2020-01-10 (Daniel Koch, Jon Leech, Christoph Kubisch)

    • Fix 'instance of' and 'that/which contains/defines' markup issues (!3528)

    • factor out VK_KHR_pipeline_library as stand-alone extension (!3540)

    • Resolve Vulkan-hpp issues (!3543)

      • add missing require for VkGeometryInstanceFlagsKHR

      • de-alias VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_CREATE_INFO_NV since the KHR structure is no longer equivalent

      • add len to pDataSize attribute for vkWriteAccelerationStructuresPropertiesKHR

  • Revision 4, 2020-01-23 (Daniel Koch, Eric Werness)

    • Improve vkWriteAccelerationStructuresPropertiesKHR, add return value and VUs (#1947)

    • Clarify language to allow multiple raygen shaders (#1959)

    • Various editorial feedback (!3556)

    • Add language to help deal with looped self-intersecting fans (#1901)

    • Change vkCmdTraceRays{,Indirect}KHR args to pointers (!3559)

    • Add scratch address validation language (#1941, !3551)

    • Fix definition and add hierarchy information for shader call scope (#1977, !3571)

  • Revision 5, 2020-02-04 (Eric Werness, Jeff Bolz, Daniel Koch)

    • remove vestigial accelerationStructureUUID (!3582)

    • update definition of repack instructions and improve memory model interactions (#1910, #1913, !3584)

    • Fix wrong sType for VkPhysicalDeviceRayTracingFeaturesKHR (#1988)

    • Use provisional SPIR-V capabilities (#1987)

    • require rayTraversalPrimitiveCulling if rayQuery is supported (#1927)

    • Miss shaders do not have object parameters (!3592)

    • Fix missing required types in XML (!3592)

    • clarify matching conditions for update (!3592)

    • add goal that host and device builds be similar (!3592)

    • clarify that maxPrimitiveCount limit should apply to triangles and AABBs (!3592)

    • Require alignment for instance arrayOfPointers (!3592)

    • Zero is a valid value for instance flags (!3592)

    • Add some alignment VUs that got lost in refactoring (!3592)

    • Recommend TMin epsilon rather than culling (!3592)

    • Get angle from dot product not cross product (!3592)

    • Clarify that AH can access the payload and attributes (!3592)

    • Match DXR behavior for inactive primitive definition (!3592)

    • Use a more generic term than degenerate for inactive to avoid confusion (!3592)

  • Revision 6, 2020-02-20 (Daniel Koch)

    • fix some dangling NV references (#1996)

    • rename VkCmdTraceRaysIndirectCommandKHR to VkTraceRaysIndirectCommandKHR (!3607)

    • update contributor list (!3611)

    • use uint64_t instead of VkAccelerationStructureReferenceKHR in VkAccelerationStructureInstanceKHR (#2004)

  • Revision 7, 2020-02-28 (Tobias Hector)

    • remove HitTKHR SPIR-V builtin (spirv/spirv-extensions#7)

  • Revision 8, 2020-03-06 (Tobias Hector, Dae Kim, Daniel Koch, Jeff Bolz, Eric Werness)

    • explicitly state that Tmax is updated when new closest intersection is accepted (#2020,!3536)

    • Made references to min and max t values consistent (!3644)

    • finish enumerating differences relative to VK_NV_ray_tracing in issues (1) and (2) (#1974,!3642)

    • fix formatting in some math equations (!3642)

    • Restrict the Hit Kind operand of OpReportIntersectionKHR to 7-bits (spirv/spirv-extensions#8,!3646)

    • Say ray tracing 'should' be watertight (#2008,!3631)

    • Clarify memory requirements for ray tracing buffers (#2005,!3649)

    • Add callable size limits (#1997,!3652)

  • Revision 9, 2020-04-15 (Eric Werness, Daniel Koch, Tobias Hector, Joshua Barczak)

    • Add geometry flags to acceleration structure creation (!3672)

    • add build scratch memory alignment (minAccelerationStructureScratchOffsetAlignment) (#2065,!3725)

    • fix naming and return enum from vkGetDeviceAccelerationStructureCompatibilityKHR (#2051,!3726)

    • require SPIR-V 1.4 (#2096,!3777)

    • added creation time capture/replay flags (#2104,!3774)

    • require Vulkan 1.1 (#2133,!3806)

    • use device addresses instead of VkBuffers for ray tracing commands (#2074,!3815)

    • add interactions with Vulkan 1.2 and VK_KHR_vulkan_memory_model (#2133,!3830)

    • make VK_KHR_pipeline_library an interaction instead of required (2108,!3830)

    • make VK_KHR_deferred_host_operations an interaction instead of required (#2045,!3830)

    • removed maxCallableSize and added explicit stack size management for ray pipelines (#1997,!3817,!3772,!3844)

    • improved documentation for VkAccelerationStructureVersionInfoKHR (#2135,3835)

    • rename VkAccelerationStructureBuildOffsetInfoKHR to VkAccelerationStructureBuildRangeInfoKHR (#2058,!3754)

    • Re-unify geometry description between build and create (!3754)

    • Fix ppGeometries ambiguity, add pGeometries (#2032,!3811)

    • add interactions with VK_EXT_robustness2 and allow nullDescriptor support for acceleration structures (#1920,!3848)

    • added future extensibility for AS updates (#2114,!3849)

    • Fix VU for dispatchrays and add a limit on the size of the full grid (#2160,!3851)

    • Add shaderGroupHandleAlignment property (#2180,!3875)

    • Clarify deferred host ops for pipeline creation (#2067,!3813)

    • Change acceleration structure build to always be sized (2197,#2198,!3854,!3883,!3880)

  • Revision 10, 2020-07-03 (Mathieu Robart, Daniel Koch, Eric Werness, Tobias Hector)

    • Decomposition of the specification, from VK_KHR_ray_tracing to VK_KHR_acceleration_structure (#1918,!3912)

    • clarify buffer usage flags for ray tracing (#2181,!3939)

    • add max primitive counts to build indirect command (#2233,!3944)

    • Allocate acceleration structures from VkBuffers and add a mode to constrain the device address (#2131,!3936)

    • Move VK_GEOMETRY_TYPE_INSTANCES_KHR to main enum (#2243,!3952)

    • make build commands more consistent (#2247,!3958)

    • add interactions with UPDATE_AFTER_BIND (#2128,!3986)

    • correct and expand build command VUs (!4020)

    • fix copy command VUs (!4018)

    • added various alignment requirements (#2229,!3943)

    • fix valid usage for arrays of geometryCount items (#2198,!4010)

    • define what is allowed to change on RTAS updates and relevant VUs (#2177,!3961)

  • Revision 11, 2020-11-12 (Eric Werness, Josh Barczak, Daniel Koch, Tobias Hector)

    • de-alias NV and KHR acceleration structure types and associated commands (#2271,!4035)

    • specify alignment for host copy commands (#2273,!4037)

    • document FORMAT_FEATURE_ACCELERATION_STRUCTURE_VERTEX_BUFFER_BIT_KHR

    • specify that acceleration structures are non-linear (#2289,!4068)

    • add several missing VUs for strides, vertexFormat, and indexType (#2315,!4069)

    • restore VUs for VkAccelerationStructureBuildGeometryInfoKHR (#2337,!4098)

    • ban multi-instance memory for host operations (#2324,!4102)

    • allow dstAccelerationStructure to be null for vkGetAccelerationStructureBuildSizesKHR (#2330,!4111)

    • more build VU cleanup (4130)

    • specify host endianness for AS serialization (#2261,!4136)

    • add invertible transform matrix VU (#1710,!4140)

    • require geometryCount to be 1 for TLAS builds (!4145)

    • improved validity conditions for build addresses (#4142)

    • add single statement SPIR-V VUs, build limit VUs (!4158)

    • document limits for vertex and aabb strides (#2390,!4184)

    • specify that PIPELINE_STAGE_ACCELERATION_STRUCTURE_BUILD_BIT_KHR applies to AS copies (4173)

    • define sync for AS build inputs and indirect buffer (#2407,!4208)

  • Revision 12, 2021-08-06 (Samuel Bourasseau)

    • rename VK_GEOMETRY_INSTANCE_TRIANGLE_FRONT_COUNTERCLOCKWISE_BIT_KHR to VK_GEOMETRY_INSTANCE_TRIANGLE_FLIP_FACING_BIT_KHR (keep previous as alias).

    • Clarify description and add note.

  • Revision 13, 2021-09-30 (Jon Leech)

    • Add interaction with VK_KHR_format_feature_flags2 to vk.xml

See Also

No cross-references are available

Document Notes

For more information, see the Vulkan Specification.

This page is a generated document. Fixes and changes should be made to the generator scripts, not directly.

  • 41 types
  • 17 values
  • Packagevulkan-3.27
  • Exports147
  • LanguageGHC2021
  • LicenceBSD-3-Clause
  • SourceVK_KHR_acceleration_structure.hs
valuedestroyAccelerationStructureKHR
  1. :: MonadIO io
  2. => Device

    device is the logical device that destroys the acceleration structure.

  3. -> AccelerationStructureKHR

    accelerationStructure is the acceleration structure to destroy.

  4. -> "allocator" ::: Maybe AllocationCallbacks

    pAllocator controls host memory allocation as described in the Memory Allocation chapter.

  5. -> io ()
#

vkDestroyAccelerationStructureKHR - Destroy an acceleration structure object

Valid Usage

  • All submitted commands that refer to accelerationStructure must have completed execution

  • If AllocationCallbacks were provided when accelerationStructure was created, a compatible set of callbacks must be provided here

  • If no AllocationCallbacks were provided when accelerationStructure was created, pAllocator must be NULL

Valid Usage (Implicit)

  • device must be a valid Device handle

  • If accelerationStructure is not NULL_HANDLE, accelerationStructure must be a valid AccelerationStructureKHR handle

  • If pAllocator is not NULL, pAllocator must be a valid pointer to a valid AllocationCallbacks structure

  • If accelerationStructure is a valid handle, it must have been created, allocated, or retrieved from device

Host Synchronization

  • Host access to accelerationStructure must be externally synchronized

See Also

VK_KHR_acceleration_structure, AccelerationStructureKHR, AllocationCallbacks, Device

valuecmdCopyAccelerationStructureKHR
  1. :: MonadIO io
  2. => CommandBuffer

    commandBuffer is the command buffer into which the command will be recorded.

  3. -> CopyAccelerationStructureInfoKHR

    pInfo is a pointer to a CopyAccelerationStructureInfoKHR structure defining the copy operation.

  4. -> io ()
#

vkCmdCopyAccelerationStructureKHR - Copy an acceleration structure

Description

This command copies the pInfo->src acceleration structure to the pInfo->dst acceleration structure in the manner specified by pInfo->mode.

Accesses to pInfo->src and pInfo->dst must be synchronized with the PIPELINE_STAGE_2_ACCELERATION_STRUCTURE_COPY_BIT_KHR pipeline stage or the PIPELINE_STAGE_ACCELERATION_STRUCTURE_BUILD_BIT_KHR pipeline stage, and an access type of ACCESS_ACCELERATION_STRUCTURE_READ_BIT_KHR or ACCESS_ACCELERATION_STRUCTURE_WRITE_BIT_KHR as appropriate.

Valid Usage

  • The source acceleration structure pInfo->src must have been constructed prior to the execution of this command on the device

  • If the source acceleration structure pInfo->src was constructed through deserialization, all micromap arrays the acceleration structure references that were not replaced by an acceleration structure update command must have been deserialized using the serialized data of the corresponding micromaps used to originally build the acceleration structure prior to the execution of this command on the device

Valid Usage (Implicit)

  • pInfo must be a valid pointer to a valid CopyAccelerationStructureInfoKHR structure

  • commandBuffer must be in the recording state

  • The CommandPool that commandBuffer was allocated from must support QUEUE_COMPUTE_BIT operations

  • This command must only be called outside of a render pass instance

  • This command must not be called between suspended render pass instances

  • This command must only be called outside of a video coding scope

Host Synchronization

  • Host access to commandBuffer must be externally synchronized

  • Host access to the CommandPool that commandBuffer was allocated from must be externally synchronized

Command Properties

'

Command Buffer Levels

Render Pass Scope

Video Coding Scope

Supported Queue Types

Command Type

Primary Secondary

Outside

Outside

VK_QUEUE_COMPUTE_BIT

Action

Conditional Rendering

vkCmdCopyAccelerationStructureKHR is not affected by conditional rendering

See Also

VK_KHR_acceleration_structure, CommandBuffer, CopyAccelerationStructureInfoKHR

valuecopyAccelerationStructureKHR
  1. :: MonadIO io
  2. => Device

    device is the device which owns the acceleration structures.

  3. -> DeferredOperationKHR

    deferredOperation is an optional DeferredOperationKHR to request deferral for this command.

  4. -> CopyAccelerationStructureInfoKHR

    pInfo is a pointer to a CopyAccelerationStructureInfoKHR structure defining the copy operation.

  5. -> io Result
#

vkCopyAccelerationStructureKHR - Copy an acceleration structure on the host

Description

This command fulfills the same task as cmdCopyAccelerationStructureKHR but is executed by the host.

Valid Usage

  • Any previous deferred operation that was associated with deferredOperation must be complete

  • pInfo->src must be bound to host-visible device memory

  • pInfo->dst must be bound to host-visible device memory

  • pInfo->src must be bound to memory that was not allocated with multiple instances

  • pInfo->dst must be bound to memory that was not allocated with multiple instances

  • The source acceleration structure pInfo->src must have been constructed prior to the execution of this command

  • If the source acceleration structure pInfo->src was constructed through deserialization, all micromap arrays the acceleration structure references that were not replaced by an acceleration structure update command must have been deserialized using the serialized data of the corresponding micromaps used to originally build the acceleration structure prior to the execution of this command

  • pInfo->src must have been created with createAccelerationStructureKHR

  • pInfo->dst must have been created with createAccelerationStructureKHR

Valid Usage (Implicit)

  • device must be a valid Device handle

Return Codes

Success
Failure

See Also

VK_KHR_acceleration_structure, CopyAccelerationStructureInfoKHR, DeferredOperationKHR, Device

valuecmdCopyAccelerationStructureToMemoryKHR
  1. :: MonadIO io
  2. => CommandBuffer

    commandBuffer is the command buffer into which the command will be recorded.

  3. -> CopyAccelerationStructureToMemoryInfoKHR

    pInfo is a pointer to a CopyAccelerationStructureToMemoryInfoKHR structure defining the copy operation.

  4. -> io ()
#

vkCmdCopyAccelerationStructureToMemoryKHR - Copy an acceleration structure to device memory

Description

Accesses to pInfo->src must be synchronized with the PIPELINE_STAGE_2_ACCELERATION_STRUCTURE_COPY_BIT_KHR pipeline stage or the PIPELINE_STAGE_ACCELERATION_STRUCTURE_BUILD_BIT_KHR pipeline stage, and an access type of ACCESS_ACCELERATION_STRUCTURE_READ_BIT_KHR. Accesses to the buffer indicated by pInfo->dst.deviceAddress must be synchronized with the PIPELINE_STAGE_2_ACCELERATION_STRUCTURE_COPY_BIT_KHR pipeline stage or the PIPELINE_STAGE_ACCELERATION_STRUCTURE_BUILD_BIT_KHR pipeline stage, and an access type of ACCESS_TRANSFER_WRITE_BIT.

This command produces the same results as copyAccelerationStructureToMemoryKHR, but writes its result to a device address, and is executed on the device rather than the host. The output may not necessarily be bit-for-bit identical, but it can be equally used by either cmdCopyMemoryToAccelerationStructureKHR or copyMemoryToAccelerationStructureKHR.

The defined header structure for the serialized data consists of:

For a top-level or bottom-level acceleration structure, this is followed by: * A 64-bit integer of the total size matching the value queried using QUERY_TYPE_ACCELERATION_STRUCTURE_SERIALIZATION_SIZE_KHR * A 64-bit integer of the deserialized size to be passed in to AccelerationStructureCreateInfoKHR::size

For a top-level acceleration structure, the remainder of the serialized header consists of:

  • A 64-bit integer of the count of the number of acceleration structure handles following. This value matches the value queried using QUERY_TYPE_ACCELERATION_STRUCTURE_SERIALIZATION_BOTTOM_LEVEL_POINTERS_KHR. For top-level acceleration structures this number is implementation-dependent; the number of and ordering of the handles may not match the instance descriptions which were used to build the acceleration structure.

The corresponding handles matching the values returned by getAccelerationStructureDeviceAddressKHR or getAccelerationStructureHandleNV are tightly packed in the buffer following the count. The application is expected to store a mapping between those handles and the original application-generated bottom-level acceleration structures to provide when deserializing.

For a bottom-level acceleration structure, the remainder of the serialized header consists of:

  • A 64-bit integer consisting of two packed 32 bit values. The high 32 bits are 0xFFFFFFFF to indicate a block-based format, and the low 32 bits contain the number of serialized blocks that follow

  • For each block:

    • A 32-bit unsigned integer indicating the block type corresponding to values in the AccelerationStructureSerializedBlockTypeKHR enumeration

    • A 32-bit reserved value for alignment

    • A 64-bit unsigned integer indicating the number of block buffer device addresses that follow the block header

    • An array of 64-bit buffer device addresses, with the count matching the previous value

If the block type is ACCELERATION_STRUCTURE_SERIALIZED_BLOCK_TYPE_OPACITY_MICROMAP_KHR, the corresponding buffer device addresses are tightly packed in the buffer and match the values returned by getBufferDeviceAddressKHR for the underlying buffer objects for the opacity micromaps. An implementation may either return NULL for a geometry with no opacity micromap or only return valid device address entries in the array. Similar to the above, the application must provide a mapping between the valid buffer device addresses and the original application-generated opacity micromaps when deserializing. If the implementation returned NULL addresses for geometry without micromaps, the application must provide NULL device addresses mapped to those when deserializing.

The addresses of micromaps provided to deserializing must be compatible with the micromaps that were used for building the acceleration structure that was serialized. They must be created before deserializing with identical type and createFlags except for the ACCELERATION_STRUCTURE_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT_KHR flag set.

Before using the deserialized acceleration structure, the micromaps must be deserialized using the serialized output of the micromap that was originally referenced by the serialized acceleration structure, or, if the acceleration structure was originally built with the BUILD_ACCELERATION_STRUCTURE_ALLOW_OPACITY_MICROMAP_UPDATE_BIT_KHR, the application may replace the micromap with a newly constructed micromap, using the normal update rules.

The serialized data is written to the buffer (or read from the buffer) according to the host endianness.

Valid Usage

Valid Usage (Implicit)

  • pInfo must be a valid pointer to a valid CopyAccelerationStructureToMemoryInfoKHR structure

  • commandBuffer must be in the recording state

  • The CommandPool that commandBuffer was allocated from must support QUEUE_COMPUTE_BIT operations

  • This command must only be called outside of a render pass instance

  • This command must not be called between suspended render pass instances

  • This command must only be called outside of a video coding scope

Host Synchronization

  • Host access to commandBuffer must be externally synchronized

  • Host access to the CommandPool that commandBuffer was allocated from must be externally synchronized

Command Properties

'

Command Buffer Levels

Render Pass Scope

Video Coding Scope

Supported Queue Types

Command Type

Primary Secondary

Outside

Outside

VK_QUEUE_COMPUTE_BIT

Action

Conditional Rendering

vkCmdCopyAccelerationStructureToMemoryKHR is not affected by conditional rendering

See Also

VK_KHR_acceleration_structure, CommandBuffer, CopyAccelerationStructureToMemoryInfoKHR

valuecopyAccelerationStructureToMemoryKHR
  1. :: MonadIO io
  2. => Device

    device is the device which owns pInfo->src.

  3. -> DeferredOperationKHR

    deferredOperation is an optional DeferredOperationKHR to request deferral for this command.

  4. -> CopyAccelerationStructureToMemoryInfoKHR

    pInfo is a pointer to a CopyAccelerationStructureToMemoryInfoKHR structure defining the copy operation.

  5. -> io Result
#

vkCopyAccelerationStructureToMemoryKHR - Serialize an acceleration structure on the host

Description

This command fulfills the same task as cmdCopyAccelerationStructureToMemoryKHR but is executed by the host.

This command produces the same results as cmdCopyAccelerationStructureToMemoryKHR, but writes its result directly to a host pointer, and is executed on the host rather than the device. The output may not necessarily be bit-for-bit identical, but it can be equally used by either cmdCopyMemoryToAccelerationStructureKHR or copyMemoryToAccelerationStructureKHR.

Valid Usage

  • Any previous deferred operation that was associated with deferredOperation must be complete

  • pInfo->src must be bound to host-visible device memory

  • pInfo->dst.hostAddress must be a valid host pointer

  • pInfo->dst.hostAddress must be aligned to 16 bytes

  • pInfo->src must not be bound to memory that was allocated with multiple instances

  • pInfo->src must have been created with createAccelerationStructureKHR

Valid Usage (Implicit)

  • device must be a valid Device handle

Return Codes

Success
Failure

See Also

VK_KHR_acceleration_structure, CopyAccelerationStructureToMemoryInfoKHR, DeferredOperationKHR, Device

valuecmdCopyMemoryToAccelerationStructureKHR
  1. :: MonadIO io
  2. => CommandBuffer

    commandBuffer is the command buffer into which the command will be recorded.

  3. -> CopyMemoryToAccelerationStructureInfoKHR

    pInfo is a pointer to a CopyMemoryToAccelerationStructureInfoKHR structure defining the copy operation.

  4. -> io ()
#

vkCmdCopyMemoryToAccelerationStructureKHR - Copy device memory to an acceleration structure

Description

Accesses to pInfo->dst must be synchronized with the PIPELINE_STAGE_2_ACCELERATION_STRUCTURE_COPY_BIT_KHR pipeline stage or the PIPELINE_STAGE_ACCELERATION_STRUCTURE_BUILD_BIT_KHR pipeline stage, and an access type of ACCESS_ACCELERATION_STRUCTURE_WRITE_BIT_KHR. Accesses to the buffer indicated by pInfo->src.deviceAddress must be synchronized with the PIPELINE_STAGE_2_ACCELERATION_STRUCTURE_COPY_BIT_KHR pipeline stage or the PIPELINE_STAGE_ACCELERATION_STRUCTURE_BUILD_BIT_KHR pipeline stage, and an access type of ACCESS_TRANSFER_READ_BIT.

This command can accept acceleration structures produced by either cmdCopyAccelerationStructureToMemoryKHR or copyAccelerationStructureToMemoryKHR.

The structure provided as input to deserialize is as described in cmdCopyAccelerationStructureToMemoryKHR, with any acceleration structure handles filled in with the newly-queried handles to bottom level acceleration structures created before deserialization. These do not need to be built at deserialize time, but must be created.

The application must also provide any required micromap addresses in the header as described in https://registry.khronos.org/vulkan/specs/latest/html/vkspec.html#serialized-as-header.

Valid Usage

Valid Usage (Implicit)

  • pInfo must be a valid pointer to a valid CopyMemoryToAccelerationStructureInfoKHR structure

  • commandBuffer must be in the recording state

  • The CommandPool that commandBuffer was allocated from must support QUEUE_COMPUTE_BIT operations

  • This command must only be called outside of a render pass instance

  • This command must not be called between suspended render pass instances

  • This command must only be called outside of a video coding scope

Host Synchronization

  • Host access to commandBuffer must be externally synchronized

  • Host access to the CommandPool that commandBuffer was allocated from must be externally synchronized

Command Properties

'

Command Buffer Levels

Render Pass Scope

Video Coding Scope

Supported Queue Types

Command Type

Primary Secondary

Outside

Outside

VK_QUEUE_COMPUTE_BIT

Action

Conditional Rendering

vkCmdCopyMemoryToAccelerationStructureKHR is not affected by conditional rendering

See Also

VK_KHR_acceleration_structure, CommandBuffer, CopyMemoryToAccelerationStructureInfoKHR

valuecopyMemoryToAccelerationStructureKHR
  1. :: MonadIO io
  2. => Device

    device is the device which owns pInfo->dst.

  3. -> DeferredOperationKHR

    deferredOperation is an optional DeferredOperationKHR to request deferral for this command.

  4. -> CopyMemoryToAccelerationStructureInfoKHR

    pInfo is a pointer to a CopyMemoryToAccelerationStructureInfoKHR structure defining the copy operation.

  5. -> io Result
#

vkCopyMemoryToAccelerationStructureKHR - Deserialize an acceleration structure on the host

Description

This command fulfills the same task as cmdCopyMemoryToAccelerationStructureKHR but is executed by the host.

This command can accept acceleration structures produced by either cmdCopyAccelerationStructureToMemoryKHR or copyAccelerationStructureToMemoryKHR.

Valid Usage

  • Any previous deferred operation that was associated with deferredOperation must be complete

  • pInfo->src.hostAddress must be a valid host pointer

  • pInfo->src.hostAddress must be aligned to 16 bytes

  • pInfo->dst must be bound to host-visible device memory

  • pInfo->dst must be bound to memory that was not allocated with multiple instances

  • pInfo->dst must have been created with createAccelerationStructureKHR

Valid Usage (Implicit)

  • device must be a valid Device handle

Return Codes

Success
Failure

See Also

VK_KHR_acceleration_structure, CopyMemoryToAccelerationStructureInfoKHR, DeferredOperationKHR, Device

valuecmdWriteAccelerationStructuresPropertiesKHR
  1. :: MonadIO io
  2. => CommandBuffer

    commandBuffer is the command buffer into which the command will be recorded.

  3. -> "accelerationStructures" ::: Vector AccelerationStructureKHR

    pAccelerationStructures is a pointer to an array of existing previously built acceleration structures.

  4. -> QueryType

    queryType is a QueryType value specifying the type of queries managed by the pool.

  5. -> QueryPool

    queryPool is the query pool that will manage the results of the query.

  6. -> "firstQuery" ::: Word32

    firstQuery is the first query index within the query pool that will contain the accelerationStructureCount number of results.

  7. -> io ()
#

vkCmdWriteAccelerationStructuresPropertiesKHR - Write acceleration structure result parameters to query results.

Description

Accesses to any of the acceleration structures listed in pAccelerationStructures must be synchronized with the PIPELINE_STAGE_2_ACCELERATION_STRUCTURE_COPY_BIT_KHR pipeline stage or the PIPELINE_STAGE_ACCELERATION_STRUCTURE_BUILD_BIT_KHR pipeline stage, and an access type of ACCESS_ACCELERATION_STRUCTURE_READ_BIT_KHR.

Valid Usage

Valid Usage (Implicit)

  • pAccelerationStructures must be a valid pointer to an array of accelerationStructureCount valid AccelerationStructureKHR handles

  • queryType must be a valid QueryType value

  • queryPool must be a valid QueryPool handle

  • commandBuffer must be in the recording state

  • The CommandPool that commandBuffer was allocated from must support QUEUE_COMPUTE_BIT operations

  • This command must only be called outside of a render pass instance

  • This command must not be called between suspended render pass instances

  • This command must only be called outside of a video coding scope

  • accelerationStructureCount must be greater than 0

  • Each of commandBuffer, queryPool, and the elements of pAccelerationStructures must have been created, allocated, or retrieved from the same Device

Host Synchronization

  • Host access to commandBuffer must be externally synchronized

  • Host access to the CommandPool that commandBuffer was allocated from must be externally synchronized

Command Properties

'

Command Buffer Levels

Render Pass Scope

Video Coding Scope

Supported Queue Types

Command Type

Primary Secondary

Outside

Outside

VK_QUEUE_COMPUTE_BIT

Action

Conditional Rendering

vkCmdWriteAccelerationStructuresPropertiesKHR is not affected by conditional rendering

See Also

VK_KHR_acceleration_structure, AccelerationStructureKHR, CommandBuffer, QueryPool, QueryType

valuewriteAccelerationStructuresPropertiesKHR
  1. :: MonadIO io
  2. => Device

    device is the device which owns the acceleration structures in pAccelerationStructures.

  3. -> "accelerationStructures" ::: Vector AccelerationStructureKHR

    pAccelerationStructures is a pointer to an array of existing previously built acceleration structures.

  4. -> QueryType

    queryType is a QueryType value specifying the property to be queried.

  5. -> "dataSize" ::: Word64

    dataSize is the size in bytes of the buffer pointed to by pData.

  6. -> "data" ::: Ptr ()

    pData is a pointer to an application-allocated buffer where the results will be written.

  7. -> "stride" ::: Word64

    stride is the stride in bytes between results for individual queries within pData.

  8. -> io ()
#

vkWriteAccelerationStructuresPropertiesKHR - Query acceleration structure meta-data on the host

Description

This command fulfills the same task as cmdWriteAccelerationStructuresPropertiesKHR but is executed by the host.

Valid Usage

Valid Usage (Implicit)

  • device must be a valid Device handle

  • pAccelerationStructures must be a valid pointer to an array of accelerationStructureCount valid AccelerationStructureKHR handles

  • queryType must be a valid QueryType value

  • pData must be a valid pointer to an array of dataSize bytes

  • accelerationStructureCount must be greater than 0

  • dataSize must be greater than 0

  • Each element of pAccelerationStructures must have been created, allocated, or retrieved from device

Return Codes

Success
Failure

See Also

VK_KHR_acceleration_structure, AccelerationStructureKHR, Device, QueryType

valuegetDeviceAccelerationStructureCompatibilityKHR
  1. :: MonadIO io
  2. => Device

    device is the device to check the version against.

  3. -> AccelerationStructureVersionInfoKHR

    pVersionInfo is a pointer to a AccelerationStructureVersionInfoKHR structure specifying version information to check against the device.

  4. -> io AccelerationStructureCompatibilityKHR
#

vkGetDeviceAccelerationStructureCompatibilityKHR - Check if a serialized acceleration structure is compatible with the current device

Valid Usage

Valid Usage (Implicit)

  • device must be a valid Device handle

See Also

VK_KHR_acceleration_structure, AccelerationStructureCompatibilityKHR, AccelerationStructureVersionInfoKHR, Device

valuecreateAccelerationStructureKHR
  1. :: (Extendss AccelerationStructureCreateInfoKHR a, PokeChain a, MonadIO io)
  2. => Device

    device is the logical device that creates the acceleration structure object.

  3. -> AccelerationStructureCreateInfoKHR a

    pCreateInfo is a pointer to a AccelerationStructureCreateInfoKHR structure containing parameters affecting creation of the acceleration structure.

  4. -> "allocator" ::: Maybe AllocationCallbacks

    pAllocator controls host memory allocation as described in the Memory Allocation chapter.

  5. -> io AccelerationStructureKHR
#

vkCreateAccelerationStructureKHR - Create a new acceleration structure object

Description

Similar to other objects in Vulkan, the acceleration structure creation merely creates an object with a specific “shape”. The type and quantity of geometry that can be built into an acceleration structure is determined by the parameters of AccelerationStructureCreateInfoKHR.

The acceleration structure data is stored in the object referred to by AccelerationStructureCreateInfoKHR::buffer. Once memory has been bound to that buffer, it must be populated by acceleration structure build or acceleration structure copy commands such as cmdBuildAccelerationStructuresKHR, buildAccelerationStructuresKHR, cmdCopyAccelerationStructureKHR, and copyAccelerationStructureKHR.

The expected usage for a trace capture/replay tool is that it will serialize and later deserialize the acceleration structure data using acceleration structure copy commands. During capture the tool will use copyAccelerationStructureToMemoryKHR or cmdCopyAccelerationStructureToMemoryKHR with a mode of COPY_ACCELERATION_STRUCTURE_MODE_SERIALIZE_KHR, and copyMemoryToAccelerationStructureKHR or cmdCopyMemoryToAccelerationStructureKHR with a mode of COPY_ACCELERATION_STRUCTURE_MODE_DESERIALIZE_KHR during replay.

Memory does not need to be bound to the underlying buffer when createAccelerationStructureKHR is called.

Valid Usage

Valid Usage (Implicit)

  • device must be a valid Device handle

Return Codes

Success
Failure

See Also

VK_KHR_acceleration_structure, AccelerationStructureCreateInfoKHR, AccelerationStructureKHR, AllocationCallbacks, Device

A convenience wrapper to make a compatible pair of calls to createAccelerationStructureKHR and destroyAccelerationStructureKHR

To ensure that destroyAccelerationStructureKHR is always called: pass bracket (or the allocate function from your favourite resource management library) as the last argument. To just extract the pair pass (,) as the last argument.

valuecmdBuildAccelerationStructuresKHR
  1. :: MonadIO io
  2. => CommandBuffer

    commandBuffer is the command buffer into which the command will be recorded.

  3. -> "infos" ::: Vector AccelerationStructureBuildGeometryInfoKHR

    pInfos is a pointer to an array of infoCount AccelerationStructureBuildGeometryInfoKHR structures defining the geometry used to build each acceleration structure.

  4. -> "buildRangeInfos" ::: Vector (Vector AccelerationStructureBuildRangeInfoKHR)

    ppBuildRangeInfos is a pointer to an array of infoCount pointers to arrays of AccelerationStructureBuildRangeInfoKHR structures. Each ppBuildRangeInfos[i] is a pointer to an array of pInfos[i].geometryCount AccelerationStructureBuildRangeInfoKHR structures defining dynamic offsets to the addresses where geometry data is stored, as defined by pInfos[i].

  5. -> io ()
#

vkCmdBuildAccelerationStructuresKHR - Build an acceleration structure

Description

The cmdBuildAccelerationStructuresKHR command provides the ability to initiate multiple acceleration structures builds, however there is no ordering or synchronization implied between any of the individual acceleration structure builds.

This means that an application cannot build a top-level acceleration structure in the same cmdBuildAccelerationStructuresKHR call as the associated bottom-level or instance acceleration structures are being built. Similarly, the application cannot build a bottom-level acceleration structure in the same cmdBuildAccelerationStructuresKHR call as the associated micromaps are being built. There also cannot be any memory aliasing between any acceleration structure memories or scratch memories being used by any of the builds.

The input buffers passed to this commands will be referenced by the implementation for the duration of this command’s execution on the device.

After the command completes, the acceleration structure may hold a reference to any acceleration structure specified by an active instance contained therein. Apart from this referencing, acceleration structures must be fully self-contained. Micromaps must always be fully-self-contained.

The application can reuse or free any memory which was used by the command as an input or as scratch without affecting the results of future commands, provided proper synchronization is used as described below.

A AccelerationStructureBuildRangeInfoKHR structure is not used when building an acceleration structure with any of the following geometry types, and must be NULL: GEOMETRY_TYPE_DENSE_GEOMETRY_FORMAT_TRIANGLES_AMDX GEOMETRY_TYPE_MICROMAP_KHR

The required alignment of the device addresses passed in to parameters below might not be provided by the base address of a Buffer created with the correct usage flags and must still be manually aligned by the application code.

Accesses to the acceleration structure scratch buffers as identified by the AccelerationStructureBuildGeometryInfoKHR::scratchData buffer device addresses must be synchronized with the PIPELINE_STAGE_ACCELERATION_STRUCTURE_BUILD_BIT_KHR pipeline stage and an access type of (ACCESS_ACCELERATION_STRUCTURE_READ_BIT_KHR | ACCESS_ACCELERATION_STRUCTURE_WRITE_BIT_KHR). Accesses to each AccelerationStructureBuildGeometryInfoKHR::srcAccelerationStructure and AccelerationStructureBuildGeometryInfoKHR::dstAccelerationStructure must be synchronized with the PIPELINE_STAGE_ACCELERATION_STRUCTURE_BUILD_BIT_KHR pipeline stage and an access type of ACCESS_ACCELERATION_STRUCTURE_READ_BIT_KHR or ACCESS_ACCELERATION_STRUCTURE_WRITE_BIT_KHR, as appropriate.

Accesses to other input buffers as identified by any used values of AccelerationStructureGeometryMotionTrianglesDataNV::vertexData, AccelerationStructureGeometryMicromapDataKHR::data, AccelerationStructureGeometryMicromapDataKHR::triangleArray, AccelerationStructureDenseGeometryFormatTrianglesDataAMDX::compressedData, AccelerationStructureGeometryTrianglesDataKHR::vertexData, AccelerationStructureGeometryTrianglesDataKHR::indexData, AccelerationStructureGeometryTrianglesDataKHR::transformData, AccelerationStructureGeometryAabbsDataKHR::data, and AccelerationStructureGeometryInstancesDataKHR::data must be synchronized with the PIPELINE_STAGE_ACCELERATION_STRUCTURE_BUILD_BIT_KHR pipeline stage and an access type of ACCESS_SHADER_READ_BIT.

Valid Usage

Valid Usage (Implicit)

  • pInfos must be a valid pointer to an array of infoCount valid AccelerationStructureBuildGeometryInfoKHR structures

  • ppBuildRangeInfos must be a valid pointer to an array of infoCount AccelerationStructureBuildRangeInfoKHR structures

  • commandBuffer must be in the recording state

  • The CommandPool that commandBuffer was allocated from must support QUEUE_COMPUTE_BIT operations

  • This command must only be called outside of a render pass instance

  • This command must not be called between suspended render pass instances

  • This command must only be called outside of a video coding scope

  • infoCount must be greater than 0

Host Synchronization

  • Host access to commandBuffer must be externally synchronized

  • Host access to the CommandPool that commandBuffer was allocated from must be externally synchronized

Command Properties

'

Command Buffer Levels

Render Pass Scope

Video Coding Scope

Supported Queue Types

Command Type

Primary Secondary

Outside

Outside

VK_QUEUE_COMPUTE_BIT

Action

Conditional Rendering

vkCmdBuildAccelerationStructuresKHR is not affected by conditional rendering

See Also

VK_KHR_acceleration_structure, AccelerationStructureBuildGeometryInfoKHR, AccelerationStructureBuildRangeInfoKHR, CommandBuffer

valuecmdBuildAccelerationStructuresIndirectKHR
  1. :: MonadIO io
  2. => CommandBuffer

    commandBuffer is the command buffer into which the command will be recorded.

  3. -> "infos" ::: Vector AccelerationStructureBuildGeometryInfoKHR

    pInfos is a pointer to an array of infoCount AccelerationStructureBuildGeometryInfoKHR structures defining the geometry used to build each acceleration structure.

  4. -> "indirectDeviceAddresses" ::: Vector DeviceAddress

    pIndirectDeviceAddresses is a pointer to an array of infoCount buffer device addresses which point to pInfos[i].geometryCount AccelerationStructureBuildRangeInfoKHR structures defining dynamic offsets to the addresses where geometry data is stored, as defined by pInfos[i].

  5. -> "indirectStrides" ::: Vector Word32

    pIndirectStrides is a pointer to an array of infoCount byte strides between elements of pIndirectDeviceAddresses.

  6. -> "maxPrimitiveCounts" ::: Vector (Vector Word32)

    ppMaxPrimitiveCounts is a pointer to an array of infoCount pointers to arrays of pInfos[i].geometryCount values indicating the maximum number of primitives that will be built by this command for each geometry.

  7. -> io ()
#

vkCmdBuildAccelerationStructuresIndirectKHR - Build an acceleration structure with some parameters provided on the device

Description

Accesses to any device memory referenced by this command must be synchronized as with cmdBuildAccelerationStructuresKHR.

Accesses to any element of pIndirectDeviceAddresses must be synchronized with the PIPELINE_STAGE_ACCELERATION_STRUCTURE_BUILD_BIT_KHR pipeline stage and an access type of ACCESS_INDIRECT_COMMAND_READ_BIT.

Valid Usage

Valid Usage (Implicit)

  • pInfos must be a valid pointer to an array of infoCount valid AccelerationStructureBuildGeometryInfoKHR structures

  • pIndirectDeviceAddresses must be a valid pointer to an array of infoCount DeviceAddress values

  • pIndirectStrides must be a valid pointer to an array of infoCount uint32_t values

  • ppMaxPrimitiveCounts must be a valid pointer to an array of infoCount uint32_t values

  • commandBuffer must be in the recording state

  • The CommandPool that commandBuffer was allocated from must support QUEUE_COMPUTE_BIT operations

  • This command must only be called outside of a render pass instance

  • This command must not be called between suspended render pass instances

  • This command must only be called outside of a video coding scope

  • infoCount must be greater than 0

Host Synchronization

  • Host access to commandBuffer must be externally synchronized

  • Host access to the CommandPool that commandBuffer was allocated from must be externally synchronized

Command Properties

'

Command Buffer Levels

Render Pass Scope

Video Coding Scope

Supported Queue Types

Command Type

Primary Secondary

Outside

Outside

VK_QUEUE_COMPUTE_BIT

Action

Conditional Rendering

vkCmdBuildAccelerationStructuresIndirectKHR is not affected by conditional rendering

See Also

VK_KHR_acceleration_structure, AccelerationStructureBuildGeometryInfoKHR, CommandBuffer, DeviceAddress

valuebuildAccelerationStructuresKHR
  1. :: MonadIO io
  2. => Device

    device is the Device for which the acceleration structures are being built.

  3. -> DeferredOperationKHR

    deferredOperation is an optional DeferredOperationKHR to request deferral for this command.

  4. -> "infos" ::: Vector AccelerationStructureBuildGeometryInfoKHR

    pInfos is a pointer to an array of infoCount AccelerationStructureBuildGeometryInfoKHR structures defining the geometry used to build each acceleration structure.

  5. -> "buildRangeInfos" ::: Vector (Vector AccelerationStructureBuildRangeInfoKHR)

    ppBuildRangeInfos is a pointer to an array of infoCount pointers to arrays of AccelerationStructureBuildRangeInfoKHR structures. Each ppBuildRangeInfos[i] is a pointer to an array of pInfos[i].geometryCount AccelerationStructureBuildRangeInfoKHR structures defining dynamic offsets to the addresses where geometry data is stored, as defined by pInfos[i].

  6. -> io Result
#

vkBuildAccelerationStructuresKHR - Build an acceleration structure on the host

Description

This command fulfills the same task as cmdBuildAccelerationStructuresKHR but is executed by the host.

The buildAccelerationStructuresKHR command provides the ability to initiate multiple acceleration structures builds, however there is no ordering or synchronization implied between any of the individual acceleration structure builds.

This means that an application cannot build a top-level acceleration structure in the same buildAccelerationStructuresKHR call as the associated bottom-level or instance acceleration structures are being built. There also cannot be any memory aliasing between any acceleration structure memories or scratch memories being used by any of the builds.

Valid Usage

Valid Usage (Implicit)

  • device must be a valid Device handle

Return Codes

Success
Failure

See Also

VK_KHR_acceleration_structure, AccelerationStructureBuildGeometryInfoKHR, AccelerationStructureBuildRangeInfoKHR, DeferredOperationKHR, Device

valuegetAccelerationStructureDeviceAddressKHR
  1. :: MonadIO io
  2. => Device

    device is the logical device that the acceleration structure was created on.

  3. -> AccelerationStructureDeviceAddressInfoKHR

    pInfo is a pointer to a AccelerationStructureDeviceAddressInfoKHR structure specifying the acceleration structure to retrieve an address for.

  4. -> io DeviceAddress
#

vkGetAccelerationStructureDeviceAddressKHR - Query an address of an acceleration structure

Description

The 64-bit return value is an address of the acceleration structure, which can be used for device and shader operations that involve acceleration structures, such as ray traversal and acceleration structure building.

If the acceleration structure was created with createAccelerationStructure2KHR, the return value will be the same address as addressRange.address.

If the acceleration structure was created with createAccelerationStructureKHR with a non-zero value of AccelerationStructureCreateInfoKHR::deviceAddress, the return value will be the same address.

Otherwise, if the acceleration structure was created with a type of ACCELERATION_STRUCTURE_TYPE_GENERIC_KHR, the returned address must be consistent with the relative offset to other acceleration structures with type ACCELERATION_STRUCTURE_TYPE_GENERIC_KHR allocated with the same Buffer. That is, the difference in returned addresses between the two must be the same as the difference in offsets provided at acceleration structure creation.

The returned address must be aligned to 256 bytes.

For acceleration structures created with createAccelerationStructureKHR, their device address may be different from the buffer device address corresponding to the acceleration structure’s start offset in its storage buffer for acceleration structure types other than ACCELERATION_STRUCTURE_TYPE_GENERIC_KHR.

Valid Usage

  • If device was created with multiple physical devices, then the bufferDeviceAddressMultiDevice feature must be enabled

  • If the buffer on which pInfo->accelerationStructure was placed is non-sparse then it must be bound completely and contiguously to a single DeviceMemory object

  • The buffer on which pInfo->accelerationStructure was placed must have been created with the BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT usage flag set

Valid Usage (Implicit)

  • device must be a valid Device handle

See Also

VK_KHR_acceleration_structure, AccelerationStructureDeviceAddressInfoKHR, Device

valuegetAccelerationStructureBuildSizesKHR
  1. :: MonadIO io
  2. => Device

    device is the logical device that will be used for creating the acceleration structure.

  3. -> AccelerationStructureBuildTypeKHR

    buildType defines whether host or device operations (or both) are being queried for.

  4. -> "buildInfo" ::: AccelerationStructureBuildGeometryInfoKHR

    pBuildInfo is a pointer to a AccelerationStructureBuildGeometryInfoKHR structure describing parameters of a build operation.

  5. -> "maxPrimitiveCounts" ::: Vector Word32

    pMaxPrimitiveCounts is a pointer to an array of pBuildInfo->geometryCount uint32_t values defining the number of primitives built into each geometry.

  6. -> io ("sizeInfo" ::: AccelerationStructureBuildSizesInfoKHR)
#

vkGetAccelerationStructureBuildSizesKHR - Retrieve the required size for an acceleration structure

Description

The srcAccelerationStructure, dstAccelerationStructure, and mode members of pBuildInfo are ignored. Any DeviceOrHostAddressKHR, DeviceOrHostAddressConstKHR, or DeviceAddress members of pBuildInfo are ignored by this command, except that the hostAddress member of AccelerationStructureGeometryTrianglesDataKHR::transformData will be examined to check if it is NULL.

An acceleration structure created with the accelerationStructureSize returned by this command supports any build or update with a AccelerationStructureBuildGeometryInfoKHR structure and array of AccelerationStructureBuildRangeInfoKHR structures subject to the following properties:

Similarly, the updateScratchSize value will support any build command specifying the BUILD_ACCELERATION_STRUCTURE_MODE_UPDATE_KHR mode under the above conditions, and the buildScratchSize value will support any build command specifying the BUILD_ACCELERATION_STRUCTURE_MODE_BUILD_KHR mode under the above conditions.

Valid Usage

Valid Usage (Implicit)

  • device must be a valid Device handle

See Also

VK_KHR_acceleration_structure, AccelerationStructureBuildGeometryInfoKHR, AccelerationStructureBuildSizesInfoKHR, AccelerationStructureBuildTypeKHR, Device

VkWriteDescriptorSetAccelerationStructureKHR - Structure specifying acceleration structure descriptor information

Valid Usage

Valid Usage (Implicit)

  • pAccelerationStructures must be a valid pointer to an array of accelerationStructureCount valid or NULL_HANDLE AccelerationStructureKHR handles

  • accelerationStructureCount must be greater than 0

Structure Chaining

Extends the structure

See Also

VK_KHR_acceleration_structure, AccelerationStructureKHR, StructureType

Constructors

Instances4Show, FromCStruct, ToCStruct, Zero

VkPhysicalDeviceAccelerationStructureFeaturesKHR - Structure describing the acceleration structure features that can be supported by an implementation

Members

This structure describes the following features:

Description

If the PhysicalDeviceAccelerationStructureFeaturesKHR structure is included in the pNext chain of the PhysicalDeviceFeatures2 structure passed to getPhysicalDeviceFeatures2, it is filled in to indicate whether each corresponding feature is supported. If the application wishes to use a Device with any features described by PhysicalDeviceAccelerationStructureFeaturesKHR, it must add an instance of the structure, with the desired feature members set to TRUE, to the pNext chain of DeviceCreateInfo when creating the Device.

Structure Chaining

Extends the structures

See Also

VK_KHR_acceleration_structure, Bool32, StructureType

Constructors

Instances6Eq, Show, Storable, FromCStruct, ToCStruct, Zero

VkPhysicalDeviceAccelerationStructurePropertiesKHR - Properties of the physical device for acceleration structure

Description

Due to the fact that the geometry, instance, and primitive counts are specified at acceleration structure creation as 32-bit values, maxGeometryCount, maxInstanceCount, and maxPrimitiveCount must not exceed 232-1.

If the PhysicalDeviceAccelerationStructurePropertiesKHR structure is included in the pNext chain of the PhysicalDeviceProperties2 structure passed to getPhysicalDeviceProperties2, it is filled in with each corresponding implementation-dependent property.

Limits specified by this structure must match those specified with the same name in PhysicalDeviceRayTracingPropertiesNV.

Structure Chaining

Extends the structure

See Also

VK_KHR_acceleration_structure, StructureType

Constructors

Instances6Eq, Show, Storable, FromCStruct, ToCStruct, Zero

VkAccelerationStructureGeometryTrianglesDataKHR - Structure specifying a triangle geometry in a bottom-level acceleration structure

Description

Unlike the stride for vertex buffers in VertexInputBindingDescription for graphics pipelines which must not exceed maxVertexInputBindingStride, vertexStride for acceleration structure geometry is instead restricted to being a 32-bit value.

Valid Usage

  • vertexStride must be a multiple of the size in bytes of the smallest component of vertexFormat

Valid Usage (Implicit)

See Also

VK_KHR_acceleration_structure, AccelerationStructureGeometryDataKHR, DeviceOrHostAddressConstKHR, DeviceSize, Format, IndexType, StructureType

Constructors

Instances4Extensible, Show, ToCStruct, Zero

VkAccelerationStructureGeometryAabbsDataKHR - Structure specifying axis-aligned bounding box geometry in a bottom-level acceleration structure

Valid Usage (Implicit)

See Also

VK_KHR_acceleration_structure, AccelerationStructureGeometryDataKHR, DeviceOrHostAddressConstKHR, DeviceSize, StructureType

Constructors

Instances3Show, ToCStruct, Zero

VkAccelerationStructureGeometryInstancesDataKHR - Structure specifying a geometry consisting of instances of other acceleration structures

Valid Usage (Implicit)

See Also

VK_KHR_acceleration_structure, AccelerationStructureGeometryDataKHR, Bool32, DeviceOrHostAddressConstKHR, StructureType

Constructors

Instances3Show, ToCStruct, Zero
datadata AccelerationStructureGeometryKHR (es :: [Type])
#

VkAccelerationStructureGeometryKHR - Structure specifying geometries to be built into an acceleration structure

Valid Usage

Valid Usage (Implicit)

See Also

VK_KHR_acceleration_structure, AccelerationStructureBuildGeometryInfoKHR, AccelerationStructureGeometryDataKHR, GeometryFlagsKHR, GeometryTypeKHR, StructureType

Constructors

Instances4Extensible, Show, ToCStruct, Zero

VkAccelerationStructureBuildGeometryInfoKHR - Structure specifying the geometry data used to build an acceleration structure

Description

Only one of pGeometries or ppGeometries can be a valid pointer, the other must be NULL. Each element of the non-NULL array describes the data used to build each acceleration structure geometry.

For bottom-level acceleration structures, the index of each element of the pGeometries or ppGeometries members of AccelerationStructureBuildGeometryInfoKHR is used as the /geometry index/ during ray traversal. The geometry index is available in ray shaders via the RayGeometryIndexKHR built-in, and is used to determine hit and intersection shaders executed during traversal. The geometry index is available to ray queries via the OpRayQueryGetIntersectionGeometryIndexKHR instruction.

Setting BUILD_ACCELERATION_STRUCTURE_MOTION_BIT_NV in flags indicates that this build is a motion top level acceleration structure. A motion top level uses instances of format AccelerationStructureMotionInstanceNV if AccelerationStructureGeometryInstancesDataKHR::arrayOfPointers is FALSE.

If AccelerationStructureGeometryInstancesDataKHR::arrayOfPointers is TRUE, the pointer for each element of the array of instance pointers consists of 4 bits of AccelerationStructureMotionInstanceTypeNV in the low 4 bits of the pointer identifying the type of structure at the pointer. The device address accessed is the value in the array with the low 4 bits set to zero. The structure at the pointer is one of AccelerationStructureInstanceKHR, AccelerationStructureMatrixMotionInstanceNV or AccelerationStructureSRTMotionInstanceNV, depending on the type value encoded in the low 4 bits.

A top level acceleration structure with either motion instances or vertex motion in its instances must set BUILD_ACCELERATION_STRUCTURE_MOTION_BIT_NV in flags.

Members srcAccelerationStructure and dstAccelerationStructure may be the same or different for an update operation (when mode is BUILD_ACCELERATION_STRUCTURE_MODE_UPDATE_KHR). If they are the same, the update happens in-place. Otherwise, the target acceleration structure is updated and the source is not modified.

Valid Usage

Valid Usage (Implicit)

  • pNext must be NULL

  • type must be a valid AccelerationStructureTypeKHR value

  • flags must be a valid combination of BuildAccelerationStructureFlagBitsKHR values

  • If geometryCount is not 0, and pGeometries is not NULL, pGeometries must be a valid pointer to an array of geometryCount valid AccelerationStructureGeometryKHR structures

  • If geometryCount is not 0, and ppGeometries is not NULL, ppGeometries must be a valid pointer to an array of geometryCount valid pointers to valid AccelerationStructureGeometryKHR structures

  • Both of dstAccelerationStructure, and srcAccelerationStructure that are valid handles of non-ignored parameters must have been created, allocated, or retrieved from the same Device

See Also

VK_KHR_acceleration_structure, AccelerationStructureGeometryKHR, AccelerationStructureKHR, AccelerationStructureTypeKHR, BuildAccelerationStructureFlagsKHR, BuildAccelerationStructureModeKHR, DeviceOrHostAddressKHR, StructureType, buildAccelerationStructuresKHR, cmdBuildAccelerationStructuresIndirectKHR, cmdBuildAccelerationStructuresKHR, getAccelerationStructureBuildSizesKHR

Constructors

Instances3Show, ToCStruct, Zero

VkAccelerationStructureBuildRangeInfoKHR - Structure specifying build offsets and counts for acceleration structure builds

Description

The primitive count and primitive offset are interpreted differently depending on the GeometryTypeKHR used:

Valid Usage

See Also

VK_KHR_acceleration_structure, buildAccelerationStructuresKHR, cmdBuildAccelerationStructuresKHR

Constructors

Instances6Eq, Show, Storable, FromCStruct, ToCStruct, Zero

VkAccelerationStructureCreateInfoKHR - Structure specifying the parameters of a newly created acceleration structure object

Description

Applications should avoid creating acceleration structures with application-provided addresses and implementation-provided addresses in the same process, to reduce the likelihood of ERROR_INVALID_OPAQUE_CAPTURE_ADDRESS_KHR errors.

The expected usage for this is that a trace capture/replay tool will add the BUFFER_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT flag to all buffers that use BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT, and will add BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT to all buffers used as storage for an acceleration structure where deviceAddress is not zero. This also means that the tool will need to add MEMORY_ALLOCATE_DEVICE_ADDRESS_BIT to memory allocations to allow the flag to be set where the application may not have otherwise required it. During capture the tool will save the queried opaque device addresses in the trace. During replay, the buffers will be created specifying the original address so any address values stored in the trace data will remain valid.

Implementations are expected to separate such buffers in the GPU address space so normal allocations will avoid using these addresses. Applications and tools should avoid mixing application-provided and implementation-provided addresses for buffers created with BUFFER_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT, to avoid address space allocation conflicts.

Applications should create an acceleration structure with a specific AccelerationStructureTypeKHR other than ACCELERATION_STRUCTURE_TYPE_GENERIC_KHR.

ACCELERATION_STRUCTURE_TYPE_GENERIC_KHR is intended to be used by API translation layers. This can be used at acceleration structure creation time in cases where the actual acceleration structure type (top or bottom) is not yet known. The actual acceleration structure type must be specified as ACCELERATION_STRUCTURE_TYPE_TOP_LEVEL_KHR, or ACCELERATION_STRUCTURE_TYPE_BOTTOM_LEVEL_KHR when the build is performed.

If the acceleration structure will be the target of a build operation, the required size for an acceleration structure can be queried with getAccelerationStructureBuildSizesKHR. If the acceleration structure is going to be the target of a compacting copy, cmdWriteAccelerationStructuresPropertiesKHR or writeAccelerationStructuresPropertiesKHR can be used to obtain the compacted size required.

If the acceleration structure will be the target of a build operation with BUILD_ACCELERATION_STRUCTURE_MOTION_BIT_NV it must include ACCELERATION_STRUCTURE_CREATE_MOTION_BIT_NV in createFlags and include AccelerationStructureMotionInfoNV as an extension structure in pNext with the number of instances as metadata for the object.

Valid Usage

Valid Usage (Implicit)

See Also

VK_KHR_acceleration_structure, AccelerationStructureCreateFlagsKHR, AccelerationStructureTypeKHR, Buffer, DeviceAddress, DeviceSize, StructureType, createAccelerationStructureKHR

Constructors

Instances5Extensible, Show, FromCStruct, ToCStruct, Zero
datadata AabbPositionsKHR
#

VkAabbPositionsKHR - Structure specifying two opposing corners of an axis-aligned bounding box

Valid Usage

See Also

VK_KHR_acceleration_structure, VK_NV_ray_tracing

Constructors

  • AabbPositionsKHR
    • minX :: Float

      minX is the x position of one opposing corner of a bounding box.

      minX must be less than or equal to maxX

    • minY :: Float

      minY is the y position of one opposing corner of a bounding box.

      minY must be less than or equal to maxY

    • minZ :: Float

      minZ is the z position of one opposing corner of a bounding box.

      minZ must be less than or equal to maxZ

    • maxX :: Float

      maxX is the x position of the other opposing corner of a bounding box.

    • maxY :: Float

      maxY is the y position of the other opposing corner of a bounding box.

    • maxZ :: Float

      maxZ is the z position of the other opposing corner of a bounding box.

Instances6Eq, Show, Storable, FromCStruct, ToCStruct, Zero
datadata TransformMatrixKHR
#

VkTransformMatrixKHR - Structure specifying a 3x4 affine transformation matrix

Valid Usage

  • The first three columns of matrix must define an invertible 3x3 matrix

See Also

VK_KHR_acceleration_structure, VK_NV_ray_tracing, AccelerationStructureInstanceKHR, AccelerationStructureMatrixMotionInstanceNV, VkPartitionedAccelerationStructureWriteInstanceDataNV

Instances6Eq, Show, Storable, FromCStruct, ToCStruct, Zero

VkAccelerationStructureInstanceKHR - Structure specifying a single acceleration structure instance for building into an acceleration structure geometry

Description

The C language specification does not define the ordering of bit-fields, but in practice, this structure produces the correct layout with existing compilers. The intended bit pattern is for the following:

  • instanceCustomIndex and mask occupy the same memory as if a single uint32_t was specified in their place

    • instanceCustomIndex occupies the 24 least significant bits of that memory

    • mask occupies the 8 most significant bits of that memory

  • instanceShaderBindingTableRecordOffset and flags occupy the same memory as if a single uint32_t was specified in their place

    • instanceShaderBindingTableRecordOffset occupies the 24 least significant bits of that memory

    • flags occupies the 8 most significant bits of that memory

If a compiler produces code that diverges from that pattern, applications must employ another method to set values according to the correct bit pattern.

Valid Usage

Valid Usage (Implicit)

See Also

VK_KHR_acceleration_structure, VK_NV_ray_tracing, AccelerationStructureMotionInstanceDataNV, GeometryInstanceFlagsKHR, TransformMatrixKHR

Constructors

Instances5Show, Storable, FromCStruct, ToCStruct, Zero

VkAccelerationStructureDeviceAddressInfoKHR - Structure specifying the acceleration structure to query an address for

Valid Usage (Implicit)

See Also

VK_KHR_acceleration_structure, AccelerationStructureKHR, StructureType, getAccelerationStructureDeviceAddressKHR

Constructors

Instances6Eq, Show, Storable, FromCStruct, ToCStruct, Zero

VkAccelerationStructureVersionInfoKHR - Acceleration structure version information

Description

pVersionData is a pointer to an array of 2×UUID_SIZE uint8_t values instead of two UUID_SIZE arrays as the expected use case for this member is to be pointed at the header of a previously serialized acceleration structure (via cmdCopyAccelerationStructureToMemoryKHR or copyAccelerationStructureToMemoryKHR) that is loaded in memory. Using arrays would necessitate extra memory copies of the UUIDs.

Valid Usage (Implicit)

See Also

VK_KHR_acceleration_structure, StructureType, getDeviceAccelerationStructureCompatibilityKHR

Constructors

Instances4Show, FromCStruct, ToCStruct, Zero

VkCopyAccelerationStructureInfoKHR - Parameters for copying an acceleration structure

Valid Usage

Valid Usage (Implicit)

See Also

VK_KHR_acceleration_structure, AccelerationStructureKHR, CopyAccelerationStructureModeKHR, StructureType, cmdCopyAccelerationStructureKHR, copyAccelerationStructureKHR

Constructors

Instances6Eq, Show, Storable, FromCStruct, ToCStruct, Zero

VkCopyAccelerationStructureToMemoryInfoKHR - Parameters for serializing an acceleration structure

Valid Usage

  • The source acceleration structure src must have been constructed prior to the execution of this command

Valid Usage (Implicit)

See Also

VK_KHR_acceleration_structure, AccelerationStructureKHR, CopyAccelerationStructureModeKHR, DeviceOrHostAddressKHR, StructureType, cmdCopyAccelerationStructureToMemoryKHR, copyAccelerationStructureToMemoryKHR

Constructors

Instances3Show, ToCStruct, Zero

VkCopyMemoryToAccelerationStructureInfoKHR - Parameters for deserializing an acceleration structure

Valid Usage

  • The source memory pointed to by src must contain data previously serialized using cmdCopyAccelerationStructureToMemoryKHR, potentially modified to relocate acceleration structure references as described in that command

Valid Usage (Implicit)

See Also

VK_KHR_acceleration_structure, AccelerationStructureKHR, CopyAccelerationStructureModeKHR, DeviceOrHostAddressConstKHR, StructureType, cmdCopyMemoryToAccelerationStructureKHR, copyMemoryToAccelerationStructureKHR

Constructors

Instances3Show, ToCStruct, Zero

VkAccelerationStructureBuildSizesInfoKHR - Structure specifying build sizes for an acceleration structure

Description

Acceleration structure objects that represent micromaps cannot be the target for update commands. Implementations must set updateScratchSize equal to 0 if the pBuildInfo->type is ACCELERATION_STRUCTURE_TYPE_OPACITY_MICROMAP_KHR.

Valid Usage (Implicit)

See Also

VK_KHR_acceleration_structure, DeviceSize, StructureType, getAccelerationStructureBuildSizesKHR, vkGetClusterAccelerationStructureBuildSizesNV, vkGetPartitionedAccelerationStructuresBuildSizesNV

Constructors

Instances6Eq, Show, Storable, FromCStruct, ToCStruct, Zero
Instances3Show, ToCStruct, Zero
newtypenewtype GeometryInstanceFlagBitsKHR
#

VkGeometryInstanceFlagBitsKHR - Instance flag bits

Description

GEOMETRY_INSTANCE_FORCE_NO_OPAQUE_BIT_KHR and GEOMETRY_INSTANCE_FORCE_OPAQUE_BIT_KHR must not be used in the same flag.

See Also

VK_KHR_acceleration_structure, VK_NV_ray_tracing, GeometryInstanceFlagsKHR

Instances8Eq, Ord, Read, Show, Bits, FiniteBits, …
newtypenewtype GeometryFlagBitsKHR
#

VkGeometryFlagBitsKHR - Bitmask specifying additional parameters for a geometry

Description

  • GEOMETRY_OPAQUE_BIT_KHR specifies that this geometry does not invoke the any-hit shaders even if present in a hit group.

  • GEOMETRY_NO_DUPLICATE_ANY_HIT_INVOCATION_BIT_KHR specifies that the implementation must only call the any-hit shader a single time for each primitive in this geometry. If this bit is absent an implementation may invoke the any-hit shader more than once for this geometry.

See Also

VK_KHR_acceleration_structure, VK_NV_ray_tracing, GeometryFlagsKHR

Instances8Eq, Ord, Read, Show, Bits, FiniteBits, …

VkBuildAccelerationStructureFlagBitsKHR - Bitmask specifying additional parameters for acceleration structure builds

Description

BUILD_ACCELERATION_STRUCTURE_ALLOW_UPDATE_BIT_KHR and BUILD_ACCELERATION_STRUCTURE_ALLOW_COMPACTION_BIT_KHR may take more time and memory than a normal build, and so should only be used when those features are needed.

BUILD_ACCELERATION_STRUCTURE_ALLOW_UPDATE_BIT_KHR and BUILD_ACCELERATION_STRUCTURE_ALLOW_COMPACTION_BIT_KHR are allowed to be used together. In that case, the result of the compaction copy is used as the source of a build with mode of BUILD_ACCELERATION_STRUCTURE_MODE_UPDATE_KHR to perform the compacted update.

See Also

VK_KHR_acceleration_structure, VK_NV_ray_tracing, BuildAccelerationStructureFlagsKHR

Instances8Eq, Ord, Read, Show, Bits, FiniteBits, …

VkAccelerationStructureCreateFlagBitsKHR - Bitmask specifying additional creation parameters for acceleration structure

Description

See Also

VK_KHR_acceleration_structure, AccelerationStructureCreateFlagsKHR

Instances8Eq, Ord, Read, Show, Bits, FiniteBits, …

VkCopyAccelerationStructureModeKHR - Acceleration structure copy mode

Description

  • COPY_ACCELERATION_STRUCTURE_MODE_CLONE_KHR creates a direct copy of the acceleration structure specified in src into the one specified by dst. The dst acceleration structure must have been created with the same parameters as src with the exception of size, which must at least as large as the queried QUERY_TYPE_ACCELERATION_STRUCTURE_SIZE_KHR size . If src contains references to other acceleration structures, dst will reference the same acceleration structures.

See Also

VK_KHR_acceleration_structure, VK_NV_ray_tracing, CopyAccelerationStructureInfoKHR, CopyAccelerationStructureToMemoryInfoKHR, CopyMemoryToAccelerationStructureInfoKHR, cmdCopyAccelerationStructureNV

Instances6Eq, Ord, Read, Show, Storable, Zero

VkBuildAccelerationStructureModeKHR - Enum specifying the type of build operation to perform

Description

See Also

VK_KHR_acceleration_structure, AccelerationStructureBuildGeometryInfoKHR

Instances6Eq, Ord, Read, Show, Storable, Zero
newtypenewtype AccelerationStructureTypeKHR
#

VkAccelerationStructureTypeKHR - Type of acceleration structure

Description

See Also

VK_KHR_acceleration_structure, VK_NV_ray_tracing, AccelerationStructureBuildGeometryInfoKHR, AccelerationStructureCreateInfo2KHR, AccelerationStructureCreateInfoKHR, AccelerationStructureInfoNV

Instances6Eq, Ord, Read, Show, Storable, Zero
newtypenewtype GeometryTypeKHR
#

VkGeometryTypeKHR - Enum specifying which type of geometry is provided

Description

See Also

VK_KHR_acceleration_structure, VK_NV_ray_tracing, AccelerationStructureGeometryKHR, GeometryNV

Instances6Eq, Ord, Read, Show, Storable, Zero

VkAccelerationStructureBuildTypeKHR - Acceleration structure build type

Description

See Also

VK_KHR_acceleration_structure, getAccelerationStructureBuildSizesKHR, getMicromapBuildSizesEXT

Instances6Eq, Ord, Read, Show, Storable, Zero

VkAccelerationStructureCompatibilityKHR - Acceleration structure compatibility

Description

See Also

VK_KHR_acceleration_structure, getDeviceAccelerationStructureCompatibilityKHR, getDeviceMicromapCompatibilityEXT

Instances6Eq, Ord, Read, Show, Storable, Zero
newtypenewtype AccelerationStructureKHR
#
Instances7Eq, Ord, Show, Storable, HasObjectType, IsHandle, …
newtypenewtype DeferredOperationKHR
#
Instances7Eq, Ord, Show, Storable, HasObjectType, IsHandle, …
newtypenewtype DebugReportObjectTypeEXT
#

VkDebugReportObjectTypeEXT - Specify the type of an object handle

Description

'

DebugReportObjectTypeEXT

Vulkan Handle Type

DEBUG_REPORT_OBJECT_TYPE_UNKNOWN_EXT

Unknown/Undefined Handle

DEBUG_REPORT_OBJECT_TYPE_INSTANCE_EXT

Instance

DEBUG_REPORT_OBJECT_TYPE_PHYSICAL_DEVICE_EXT

PhysicalDevice

DEBUG_REPORT_OBJECT_TYPE_DEVICE_EXT

Device

DEBUG_REPORT_OBJECT_TYPE_QUEUE_EXT

Queue

DEBUG_REPORT_OBJECT_TYPE_SEMAPHORE_EXT

Semaphore

DEBUG_REPORT_OBJECT_TYPE_COMMAND_BUFFER_EXT

CommandBuffer

DEBUG_REPORT_OBJECT_TYPE_FENCE_EXT

Fence

DEBUG_REPORT_OBJECT_TYPE_DEVICE_MEMORY_EXT

DeviceMemory

DEBUG_REPORT_OBJECT_TYPE_BUFFER_EXT

Buffer

DEBUG_REPORT_OBJECT_TYPE_IMAGE_EXT

Image

DEBUG_REPORT_OBJECT_TYPE_EVENT_EXT

Event

DEBUG_REPORT_OBJECT_TYPE_QUERY_POOL_EXT

QueryPool

DEBUG_REPORT_OBJECT_TYPE_BUFFER_VIEW_EXT

BufferView

DEBUG_REPORT_OBJECT_TYPE_IMAGE_VIEW_EXT

ImageView

DEBUG_REPORT_OBJECT_TYPE_SHADER_MODULE_EXT

ShaderModule

DEBUG_REPORT_OBJECT_TYPE_PIPELINE_CACHE_EXT

PipelineCache

DEBUG_REPORT_OBJECT_TYPE_PIPELINE_LAYOUT_EXT

PipelineLayout

DEBUG_REPORT_OBJECT_TYPE_RENDER_PASS_EXT

RenderPass

DEBUG_REPORT_OBJECT_TYPE_PIPELINE_EXT

Pipeline

DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_SET_LAYOUT_EXT

DescriptorSetLayout

DEBUG_REPORT_OBJECT_TYPE_SAMPLER_EXT

Sampler

DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_POOL_EXT

DescriptorPool

DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_SET_EXT

DescriptorSet

DEBUG_REPORT_OBJECT_TYPE_FRAMEBUFFER_EXT

Framebuffer

DEBUG_REPORT_OBJECT_TYPE_COMMAND_POOL_EXT

CommandPool

DEBUG_REPORT_OBJECT_TYPE_SURFACE_KHR_EXT

SurfaceKHR

DEBUG_REPORT_OBJECT_TYPE_SWAPCHAIN_KHR_EXT

SwapchainKHR

DEBUG_REPORT_OBJECT_TYPE_DEBUG_REPORT_CALLBACK_EXT_EXT

DebugReportCallbackEXT

DEBUG_REPORT_OBJECT_TYPE_DISPLAY_KHR_EXT

DisplayKHR

DEBUG_REPORT_OBJECT_TYPE_DISPLAY_MODE_KHR_EXT

DisplayModeKHR

DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_EXT

DescriptorUpdateTemplate

DebugReportObjectTypeEXT and Vulkan Handle Relationship

The primary expected use of ERROR_VALIDATION_FAILED_EXT is for validation layer testing to prevent invalid commands from reaching the ICD. It is not expected that an application would see this error code during normal use of the validation layers. If an application returns TRUE in DebugUtilsMessengerCallbackDataEXT, the validation layers will return this error code instead of passing the command down the dispatch chain.

See Also

PFN_vkDebugReportCallbackEXT, VK_EXT_debug_marker, VK_EXT_debug_report, DebugMarkerObjectNameInfoEXT, DebugMarkerObjectTagInfoEXT, debugReportMessageEXT

Instances6Eq, Ord, Read, Show, Storable, Zero