Package org.lwjgl.vulkan

Class VkAccelerationStructureCreateInfoKHR

java.lang.Object
org.lwjgl.system.Pointer.Default
org.lwjgl.system.Struct<VkAccelerationStructureCreateInfoKHR>
org.lwjgl.vulkan.VkAccelerationStructureCreateInfoKHR
All Implemented Interfaces:
AutoCloseable, org.lwjgl.system.NativeResource, org.lwjgl.system.Pointer
public class VkAccelerationStructureCreateInfoKHR extends org.lwjgl.system.Struct<VkAccelerationStructureCreateInfoKHR> implements org.lwjgl.system.NativeResource
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.

Note

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 VkAccelerationStructureTypeKHR other than ACCELERATION_STRUCTURE_TYPE_GENERIC_KHR.

Note

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 VkAccelerationStructureMotionInfoNV as an extension structure in pNext with the number of instances as metadata for the object.

Valid Usage
Valid Usage (Implicit)
See Also

CreateAccelerationStructureKHR

Layout


 struct VkAccelerationStructureCreateInfoKHR {
     VkStructureType sType();
     void const * pNext();
     VkAccelerationStructureCreateFlagsKHR createFlags();
     VkBuffer buffer();
     VkDeviceSize offset();
     VkDeviceSize size();
     VkAccelerationStructureTypeKHR type();
     VkDeviceAddress deviceAddress();
 }