VkAccelerationStructureCreateInfo2KHR(3)

Name

VkAccelerationStructureCreateInfo2KHR - Structure specifying the parameters of a newly created acceleration structure object using a device address

C Specification

The VkAccelerationStructureCreateInfo2KHR structure is defined as:

// Provided by VK_KHR_acceleration_structure with VK_KHR_device_address_commands
typedef struct VkAccelerationStructureCreateInfo2KHR {
    VkStructureType                          sType;
    const void*                              pNext;
    VkAccelerationStructureCreateFlagsKHR    createFlags;
    VkDeviceAddressRangeKHR                  addressRange;
    VkAddressCommandFlagsKHR                 addressFlags;
    VkAccelerationStructureTypeKHR           type;
} VkAccelerationStructureCreateInfo2KHR;

Members

Description

Applications should create an acceleration structure with a specific VkAccelerationStructureTypeKHR other than VK_ACCELERATION_STRUCTURE_TYPE_GENERIC_KHR.

VK_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 VK_ACCELERATION_STRUCTURE_TYPE_TOP_LEVEL_KHR or VK_ACCELERATION_STRUCTURE_TYPE_BOTTOM_LEVEL_KHR when the build is performed.

During replay, if createFlags includes VK_ACCELERATION_STRUCTURE_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT_KHR, addressRange.address must be an address used to create an identical acceleration structure on the same implementation. The address must be in the range of an identically created VkBuffer at the same offset.

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

The expected usage for this is that a trace capture/replay tool will add the VK_BUFFER_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT flag and VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT to all buffers used as storage for an acceleration structure with VK_ACCELERATION_STRUCTURE_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT_KHR included in createFlags. This also means that the tool will need to add VK_MEMORY_ALLOCATE_DEVICE_ADDRESS_BIT to memory allocations to allow the VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT 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 VK_BUFFER_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT, to avoid address space allocation conflicts.

If the acceleration structure will be the target of a build operation, the required size for an acceleration structure can be queried with vkGetAccelerationStructureBuildSizesKHR. If the acceleration structure is going to be the target of a copy, vkCmdWriteAccelerationStructuresPropertiesKHR can be used to obtain the size required depending on the type of copy.

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

Valid Usage
Valid Usage (Implicit)

Document Notes

For more information, see the Vulkan Specification.

This page is extracted from the Vulkan Specification. Fixes and changes should be made to the Specification, not directly.