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

GHC 9.14.1 · lts/ghc-9.14.x · 45dd537 · 2026-10-11

Modulevulkan-3.27GHC2021

Vulkan.Extensions.VK_EXT_opacity_micromap

Name

VK_EXT_opacity_micromap - device extension

VK_EXT_opacity_micromap

Name String

VK_EXT_opacity_micromap

Extension Type

Device extension

Registered Extension Number

397

Revision

2

Ratification Status

Ratified

Extension and Version Dependencies

VK_KHR_acceleration_structure

and

VK_KHR_synchronization2      or

Vulkan Version 1.3

API Interactions
  • Interacts with VK_VERSION_1_4

  • Interacts with VK_KHR_maintenance5

SPIR-V Dependencies
Deprecation State
Contact
Extension Proposal

VK_EXT_opacity_micromap

Other Extension Metadata

Last Modified Date

2022-08-24

Interactions and External Dependencies
Contributors
  • Christoph Kubisch, NVIDIA

  • Eric Werness, NVIDIA

  • Josh Barczak, Intel

  • Stu Smith, AMD

Description

When adding transparency to a ray traced scene, an application can choose between further tessellating the geometry or using an any-hit shader to allow the ray through specific parts of the geometry. These options have the downside of either significantly increasing memory consumption or adding runtime overhead to run shader code in the middle of traversal, respectively.

This extension adds the ability to add an opacity micromap to geometry when building an acceleration structure. The opacity micromap compactly encodes opacity information which can be read by the implementation to mark parts of triangles as opaque or transparent. The format is externally visible to allow the application to compress its internal geometry and surface representations into the compressed format ahead of time. The compressed format subdivides each triangle into a set of subtriangles, each of which can be assigned either two or four opacity values. These opacity values can control if a ray hitting that subtriangle is treated as an opaque hit, complete miss, or possible hit, depending on the controls described in Ray Opacity Micromap.

This extension provides:

  • a MicromapEXT structure to store the micromap,

  • functions similar to acceleration structure build functions to build the opacity micromap array, and

  • a structure to extend AccelerationStructureGeometryTrianglesDataKHR to attach a micromap to the geometry of the acceleration structure.

New Object Types

New Commands

New Structures

New Enums

New Bitmasks

New Enum Constants

If VK_KHR_maintenance5 or Vulkan Version 1.4 is supported:

Promotion to VK_KHR_opacity_micromap

Functionality in this extension is included in VK_KHR_opacity_micromap. The type, enum and command names are still aliases of the KHR functionality with some exceptions.

See the VK_KHR_opacity_micromap proposal for details on the differences.

Reference Code

uint32_t BarycentricsToSpaceFillingCurveIndex(float u, float v, uint32_t level)
{
    u = clamp(u, 0.0f, 1.0f);
    v = clamp(v, 0.0f, 1.0f);

    uint32_t iu, iv, iw;

    // Quantize barycentric coordinates
    float fu = u * (1u << level);
    float fv = v * (1u << level);

    iu = (uint32_t)fu;
    iv = (uint32_t)fv;

    float uf = fu - float(iu);
    float vf = fv - float(iv);

    if (iu >= (1u << level)) iu = (1u << level) - 1u;
    if (iv >= (1u << level)) iv = (1u << level) - 1u;

    uint32_t iuv = iu + iv;

    if (iuv >= (1u << level))
        iu -= iuv - (1u << level) + 1u;

    iw = ~(iu + iv);

    if (uf + vf >= 1.0f && iuv < (1u << level) - 1u) --iw;

    uint32_t b0 = ~(iu ^ iw);
    b0 &= ((1u << level) - 1u);
    uint32_t t = (iu ^ iv) & b0;

    uint32_t f = t;
    f ^= f >> 1u;
    f ^= f >> 2u;
    f ^= f >> 4u;
    f ^= f >> 8u;
    uint32_t b1 = ((f ^ iu) & ~b0) | t;

    // Interleave bits
    b0 = (b0 | (b0 << 8u)) & 0x00ff00ffu;
    b0 = (b0 | (b0 << 4u)) & 0x0f0f0f0fu;
    b0 = (b0 | (b0 << 2u)) & 0x33333333u;
    b0 = (b0 | (b0 << 1u)) & 0x55555555u;
    b1 = (b1 | (b1 << 8u)) & 0x00ff00ffu;
    b1 = (b1 | (b1 << 4u)) & 0x0f0f0f0fu;
    b1 = (b1 | (b1 << 2u)) & 0x33333333u;
    b1 = (b1 | (b1 << 1u)) & 0x55555555u;

    return b0 | (b1 << 1u);
}

Issues

  1. Is the build actually similar to an acceleration structure build?

  • Resolved: The build should be much lighter-weight than an acceleration structure build, but the infrastructure is similar enough that it makes sense to keep the concepts compatible.

  1. Why does VkMicromapUsageEXT not have type/pNext?

  • Resolved: There can be a very large number of these structures, so doubling the size of these can be significant memory consumption. Also, an application may be loading these directly from a file which is more compatible with it being a flat structure. The including structures are extensible and are probably a more suitable place to add extensibility.

  1. Why is there a SPIR-V extension?

  • Resolved: There is a ray flag. To be consistent with how the existing ray tracing extensions work that ray flag needs its own extension.

  1. Should there be indirect micromap build?

  • Resolved: Not for now. There is more in-depth usage metadata required and it seems less likely that something like a GPU culling system would need to change the counts for a micromap.

  1. Should micromaps have a micromap device address?

  • Resolved: There is no need right now (can just use the handle) but that is a bit different from acceleration structures, though the two are not completely parallel in their usage.

  1. Why are the alignment requirements defined as a mix of hardcoded values and caps?

  • Resolved: This is most parallel with the definition of VK_KHR_acceleration_structure and maintaining commonality makes it easier for applications to share memory.

Version History

  • Revision 2, 2022-06-22 (Eric Werness)

    • EXTify and clean up for discussion

  • Revision 1, 2022-01-01 (Eric Werness)

    • Initial revision

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.

  • 36 types
  • 15 values
  • Packagevulkan-3.27
  • Exports110
  • LanguageGHC2021
  • LicenceBSD-3-Clause
  • SourceVK_EXT_opacity_micromap.hs
valuecreateMicromapEXT
  1. :: MonadIO io
  2. => Device

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

  3. -> MicromapCreateInfoEXT

    pCreateInfo is a pointer to a MicromapCreateInfoEXT structure containing parameters affecting creation of the micromap.

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

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

  5. -> io MicromapEXT
#

vkCreateMicromapEXT - Create a new micromap object

Description

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

The micromap data is stored in the object referred to by MicromapCreateInfoEXT::buffer. Once memory has been bound to that buffer, it must be populated by micromap build or micromap copy commands such as cmdBuildMicromapsEXT, buildMicromapsEXT, cmdCopyMicromapEXT, and copyMicromapEXT.

The expected usage for a trace capture/replay tool is that it will serialize and later deserialize the micromap data using micromap copy commands. During capture the tool will set CopyMicromapToMemoryInfoEXT::mode to COPY_MICROMAP_MODE_SERIALIZE_EXT, and during replay the tool will set CopyMemoryToMicromapInfoEXT::mode to COPY_MICROMAP_MODE_DESERIALIZE_EXT.

Valid Usage

Valid Usage (Implicit)

  • device must be a valid Device handle

  • pCreateInfo must be a valid pointer to a valid MicromapCreateInfoEXT structure

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

  • pMicromap must be a valid pointer to a MicromapEXT handle

  • The device must have been created with at least 1 queue

Return Codes

Success
Failure

See Also

VK_EXT_opacity_micromap, AllocationCallbacks, Device, MicromapCreateInfoEXT, MicromapEXT

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

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

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

    pInfos is a pointer to an array of infoCount MicromapBuildInfoEXT structures defining the data used to build each micromap.

  4. -> io ()
#

vkCmdBuildMicromapsEXT - Build a micromap

Description

The cmdBuildMicromapsEXT command provides the ability to initiate multiple micromaps builds, however there is no ordering or synchronization implied between any of the individual micromap builds.

This means that there cannot be any memory aliasing between any micromap memories or scratch memories being used by any of the builds.

The input buffers passed to this command will be referenced by the implementation for the duration of the command’s execution on the device. Micromaps must be fully self-contained. The application can reuse or free any memory which was used by this command’s execution on the device as an input or as scratch without affecting the results of a subsequent acceleration structure build using the micromap or traversal of that acceleration structure, provided proper synchronization is used as described below.

Accesses to the micromap scratch buffers as identified by the MicromapBuildInfoEXT::scratchData buffer device addresses must be synchronized with the PIPELINE_STAGE_2_MICROMAP_BUILD_BIT_EXT pipeline stage and an access type of (ACCESS_2_MICROMAP_READ_BIT_EXT | ACCESS_2_MICROMAP_WRITE_BIT_EXT). Accesses to MicromapBuildInfoEXT::dstMicromap must be synchronized with the PIPELINE_STAGE_2_MICROMAP_BUILD_BIT_EXT pipeline stage and an access type of ACCESS_2_MICROMAP_WRITE_BIT_EXT.

Accesses to other input buffers as identified by any used values of MicromapBuildInfoEXT::data or MicromapBuildInfoEXT::triangleArray must be synchronized with the PIPELINE_STAGE_2_MICROMAP_BUILD_BIT_EXT pipeline stage and an access type of ACCESS_SHADER_READ_BIT.

Valid Usage

  • For each pInfos[i], dstMicromap must have been created with a value of MicromapCreateInfoEXT::size greater than or equal to the memory size required by the build operation, as returned by getMicromapBuildSizesEXT with pBuildInfo = pInfos[i]

  • The mode member of each element of pInfos must be a valid BuildMicromapModeEXT value

  • The dstMicromap member of any element of pInfos must be a valid MicromapEXT handle

  • For each element of pInfos its type member must match the value of MicromapCreateInfoEXT::type when its dstMicromap was created

  • The ::micromap feature must be enabled

  • For each element of pInfos, the buffer used to create its dstMicromap member must be bound to device memory

  • If pInfos[i].mode is BUILD_MICROMAP_MODE_BUILD_EXT, all addresses between pInfos[i].scratchData.deviceAddress and pInfos[i].scratchData.deviceAddress + N - 1 must be in the buffer device address range of the same buffer, where N is given by the buildScratchSize member of the MicromapBuildSizesInfoEXT structure returned from a call to getMicromapBuildSizesEXT with an identical MicromapBuildInfoEXT structure and primitive count

  • The buffers from which the buffer device addresses for all of the data and triangleArray members of all pInfos[i] are queried must have been created with the BUFFER_USAGE_MICROMAP_BUILD_INPUT_READ_ONLY_BIT_EXT usage flag set

  • For each element of pInfos[i] the buffer from which the buffer device address pInfos[i].scratchData.deviceAddress is queried must have been created with the BUFFER_USAGE_STORAGE_BUFFER_BIT usage flag set

  • For each element of pInfos, if the value of MicromapBuildSizesInfoEXT::buildScratchSize, returned from a call to getMicromapBuildSizesEXT with an identical MicromapBuildInfoEXT structure, is not 0, scratchData.deviceAddress must be a valid DeviceAddress

  • For each element of pInfos, data.deviceAddress must be a valid DeviceAddress

  • For each element of pInfos, triangleArray.deviceAddress must be a valid DeviceAddress

  • For each element of pInfos, its scratchData.deviceAddress member must be a multiple of PhysicalDeviceAccelerationStructurePropertiesKHR::minAccelerationStructureScratchOffsetAlignment

  • For each element of pInfos, its triangleArray.deviceAddress and data.deviceAddress members must be a multiple of 256

  • The range of memory backing the dstMicromap member of any element of pInfos that is accessed by the execution of this command on the device must not overlap the memory backing the dstMicromap member of any other element of pInfos, which is accessed by the execution of this command on the device

  • The range of memory backing the dstMicromap member of any element of pInfos that is accessed by the execution of this command on the device must not overlap the memory backing the scratchData member of any element of pInfos (including the same element), which is accessed by the execution of this command on the device

  • The range of memory backing the scratchData member of any element of pInfos that is accessed by the execution of this command on the device must not overlap the memory backing the scratchData member of any other element of pInfos, which is accessed by the execution of this command on the device

Valid Usage (Implicit)

  • pInfos must be a valid pointer to an array of infoCount valid MicromapBuildInfoEXT 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

vkCmdBuildMicromapsEXT is not affected by conditional rendering

See Also

VK_EXT_opacity_micromap, CommandBuffer, MicromapBuildInfoEXT

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

    device is the Device for which the micromaps are being built.

  3. -> DeferredOperationKHR

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

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

    pInfos is a pointer to an array of infoCount MicromapBuildInfoEXT structures defining the geometry used to build each micromap.

  5. -> io Result
#

vkBuildMicromapsEXT - Build a micromap on the host

Description

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

The buildMicromapsEXT command provides the ability to initiate multiple micromaps builds, however there is no ordering or synchronization implied between any of the individual micromap builds.

This means that there cannot be any memory aliasing between any micromap memories or scratch memories being used by any of the builds.

The input buffers passed to this command will be referenced by the implementation for the duration of the command. Micromaps must 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 a subsequent acceleration structure build using the micromap or traversal of that acceleration structure.

Valid Usage

  • For each pInfos[i], dstMicromap must have been created with a value of MicromapCreateInfoEXT::size greater than or equal to the memory size required by the build operation, as returned by getMicromapBuildSizesEXT with pBuildInfo = pInfos[i]

  • The mode member of each element of pInfos must be a valid BuildMicromapModeEXT value

  • The dstMicromap member of any element of pInfos must be a valid MicromapEXT handle

  • For each element of pInfos its type member must match the value of MicromapCreateInfoEXT::type when its dstMicromap was created

  • For each element of pInfos, the buffer used to create its dstMicromap member must be bound to host-visible device memory

  • For each element of pInfos, all referenced addresses of pInfos[i].data.hostAddress must be valid host memory

  • For each element of pInfos, all referenced addresses of pInfos[i].triangleArray.hostAddress must be valid host memory

  • The ::micromapHostCommands feature must be enabled

  • If pInfos[i].mode is BUILD_MICROMAP_MODE_BUILD_EXT, and N is not 0, then all addresses between pInfos[i].scratchData.hostAddress and pInfos[i].scratchData.hostAddress + N - 1 must be valid host memory, where N is given by the value of MicromapBuildSizesInfoEXT::buildScratchSize returned from a call to getMicromapBuildSizesEXT with an identical MicromapBuildInfoEXT structure

  • For each element of pInfos, the buffer used to create its dstMicromap member must be bound to memory that was not allocated with multiple instances

  • The range of memory backing the dstMicromap member of any element of pInfos that is accessed by this command must not overlap the memory backing the dstMicromap member of any other element of pInfos, which is accessed by this command

  • The range of memory backing the dstMicromap member of any element of pInfos that is accessed by this command must not overlap the memory backing the scratchData member of any element of pInfos (including the same element), which is accessed by this command

  • The range of memory backing the scratchData member of any element of pInfos that is accessed by this command must not overlap the memory backing the scratchData member of any other element of pInfos, which is accessed by this command

Valid Usage (Implicit)

  • device must be a valid Device handle

  • If deferredOperation is not NULL_HANDLE, deferredOperation must be a valid DeferredOperationKHR handle

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

  • infoCount must be greater than 0

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

Return Codes

Success
Failure

See Also

VK_EXT_opacity_micromap, DeferredOperationKHR, Device, MicromapBuildInfoEXT

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

    device is the logical device that destroys the micromap.

  3. -> MicromapEXT

    micromap is the micromap to destroy.

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

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

  5. -> io ()
#

vkDestroyMicromapEXT - Destroy a micromap object

Valid Usage

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

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

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

Valid Usage (Implicit)

  • device must be a valid Device handle

  • If micromap is not NULL_HANDLE, micromap must be a valid MicromapEXT handle

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

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

Host Synchronization

  • Host access to micromap must be externally synchronized

See Also

VK_EXT_opacity_micromap, AllocationCallbacks, Device, MicromapEXT

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

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

  3. -> CopyMicromapInfoEXT

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

  4. -> io ()
#

vkCmdCopyMicromapEXT - Copy a micromap

Description

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

Accesses to pInfo->src and pInfo->dst must be synchronized with the PIPELINE_STAGE_2_MICROMAP_BUILD_BIT_EXT pipeline stage and an access type of ACCESS_2_MICROMAP_READ_BIT_EXT or ACCESS_2_MICROMAP_WRITE_BIT_EXT as appropriate.

Valid Usage

  • The buffer used to create pInfo->src must be bound to device memory

  • The buffer used to create pInfo->dst must must be bound to device memory

  • The source micromap src must have been constructed prior to the execution of this command on the device

Valid Usage (Implicit)

  • pInfo must be a valid pointer to a valid CopyMicromapInfoEXT 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

vkCmdCopyMicromapEXT is not affected by conditional rendering

See Also

VK_EXT_opacity_micromap, CommandBuffer, CopyMicromapInfoEXT

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

    device is the device which owns the micromaps.

  3. -> DeferredOperationKHR

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

  4. -> CopyMicromapInfoEXT

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

  5. -> io Result
#

vkCopyMicromapEXT - Copy a micromap on the host

Description

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

Valid Usage

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

  • The buffer used to create pInfo->src must be bound to host-visible device memory

  • The buffer used to create pInfo->dst must be bound to host-visible device memory

  • The ::micromapHostCommands feature must be enabled

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

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

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

Valid Usage (Implicit)

  • device must be a valid Device handle

  • If deferredOperation is not NULL_HANDLE, deferredOperation must be a valid DeferredOperationKHR handle

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

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

Return Codes

Success
Failure

See Also

VK_EXT_opacity_micromap, CopyMicromapInfoEXT, DeferredOperationKHR, Device

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

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

  3. -> CopyMicromapToMemoryInfoEXT

    pInfo is an a pointer to a CopyMicromapToMemoryInfoEXT structure defining the copy operation.

  4. -> io ()
#

vkCmdCopyMicromapToMemoryEXT - Copy a micromap to device memory

Description

Accesses to pInfo->src must be synchronized with the PIPELINE_STAGE_2_MICROMAP_BUILD_BIT_EXT pipeline stage and an access type of ACCESS_2_MICROMAP_READ_BIT_EXT. Accesses to the buffer indicated by pInfo->dst must be synchronized with the PIPELINE_STAGE_2_MICROMAP_BUILD_BIT_EXT pipeline stage and an access type of ACCESS_TRANSFER_WRITE_BIT.

This command produces the same results as copyMicromapToMemoryEXT, 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 is equally compatible for use with either cmdCopyMemoryToMicromapEXT or copyMemoryToMicromapEXT.

The defined header structure for the serialized data consists of:

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

Valid Usage

  • pInfo->dst.deviceAddress must be aligned to 256 bytes

  • The buffer used to create pInfo->src must be bound to device memory

Valid Usage (Implicit)

  • pInfo must be a valid pointer to a valid CopyMicromapToMemoryInfoEXT 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

vkCmdCopyMicromapToMemoryEXT is not affected by conditional rendering

See Also

VK_EXT_opacity_micromap, CommandBuffer, CopyMicromapToMemoryInfoEXT

valuecopyMicromapToMemoryEXT
  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. -> CopyMicromapToMemoryInfoEXT

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

  5. -> io Result
#

vkCopyMicromapToMemoryEXT - Serialize a micromap on the host

Description

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

This command produces the same results as cmdCopyMicromapToMemoryEXT, 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 is compatible for use with either cmdCopyMemoryToMicromapEXT or copyMemoryToMicromapEXT.

Valid Usage

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

  • The buffer used to create 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

  • The ::micromapHostCommands feature must be enabled

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

Valid Usage (Implicit)

  • device must be a valid Device handle

Return Codes

Success
Failure

See Also

VK_EXT_opacity_micromap, CopyMicromapToMemoryInfoEXT, DeferredOperationKHR, Device

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

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

  3. -> CopyMemoryToMicromapInfoEXT

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

  4. -> io ()
#

vkCmdCopyMemoryToMicromapEXT - Copy device memory to a micromap

Description

Accesses to pInfo->dst must be synchronized with the PIPELINE_STAGE_2_MICROMAP_BUILD_BIT_EXT pipeline stage and an access type of ACCESS_2_MICROMAP_WRITE_BIT_EXT. Accesses to the buffer indicated by pInfo->src must be synchronized with the PIPELINE_STAGE_2_MICROMAP_BUILD_BIT_EXT pipeline stage and an access type of ACCESS_TRANSFER_READ_BIT.

This command can accept micromaps produced by either copyMicromapToMemoryEXT or cmdCopyMicromapToMemoryEXT.

Valid Usage

  • pInfo->src.deviceAddress must be aligned to 256 bytes

  • The buffer used to create pInfo->dst must be bound to device memory

Valid Usage (Implicit)

  • pInfo must be a valid pointer to a valid CopyMemoryToMicromapInfoEXT 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

vkCmdCopyMemoryToMicromapEXT is not affected by conditional rendering

See Also

VK_EXT_opacity_micromap, CommandBuffer, CopyMemoryToMicromapInfoEXT

valuecopyMemoryToMicromapEXT
  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. -> CopyMemoryToMicromapInfoEXT

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

  5. -> io Result
#

vkCopyMemoryToMicromapEXT - Deserialize a micromap on the host

Description

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

This command can accept micromaps produced by either cmdCopyMicromapToMemoryEXT or copyMicromapToMemoryEXT.

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

  • The buffer used to create pInfo->dst must be bound to host-visible device memory

  • The ::micromapHostCommands feature must be enabled

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

Valid Usage (Implicit)

  • device must be a valid Device handle

Return Codes

Success
Failure

See Also

VK_EXT_opacity_micromap, CopyMemoryToMicromapInfoEXT, DeferredOperationKHR, Device

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

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

  3. -> "micromaps" ::: Vector MicromapEXT

    pMicromaps is a pointer to an array of existing previously built micromaps.

  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 micromapCount number of results.

  7. -> io ()
#

vkCmdWriteMicromapsPropertiesEXT - Write micromap result parameters to query results.

Description

Accesses to any of the micromaps listed in pMicromaps must be synchronized with the PIPELINE_STAGE_2_MICROMAP_BUILD_BIT_EXT pipeline stage and an access type of ACCESS_2_MICROMAP_READ_BIT_EXT.

Valid Usage

  • queryPool must have been created with a queryType matching queryType

Valid Usage (Implicit)

  • pMicromaps must be a valid pointer to an array of micromapCount valid MicromapEXT handles

  • 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

  • micromapCount must be greater than 0

  • Each of commandBuffer, queryPool, and the elements of pMicromaps 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

vkCmdWriteMicromapsPropertiesEXT is not affected by conditional rendering

See Also

VK_EXT_opacity_micromap, CommandBuffer, MicromapEXT, QueryPool, QueryType

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

    device is the device which owns the micromaps in pMicromaps.

  3. -> "micromaps" ::: Vector MicromapEXT

    pMicromaps is a pointer to an array of existing previously built micromaps.

  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 ()
#

vkWriteMicromapsPropertiesEXT - Query micromap meta-data on the host

Description

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

Valid Usage

Valid Usage (Implicit)

  • device must be a valid Device handle

  • pMicromaps must be a valid pointer to an array of micromapCount valid MicromapEXT handles

  • queryType must be a valid QueryType value

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

  • micromapCount must be greater than 0

  • dataSize must be greater than 0

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

Return Codes

Success
Failure

See Also

VK_EXT_opacity_micromap, Device, MicromapEXT, QueryType

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

    device is the device to check the version against.

  3. -> MicromapVersionInfoEXT

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

  4. -> io AccelerationStructureCompatibilityKHR
#

vkGetDeviceMicromapCompatibilityEXT - Check if a serialized micromap is compatible with the current device

Valid Usage

Valid Usage (Implicit)

  • device must be a valid Device handle

See Also

VK_EXT_opacity_micromap, AccelerationStructureCompatibilityKHR, Device, MicromapVersionInfoEXT

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

    device is the logical device that will be used for creating the micromap.

  3. -> AccelerationStructureBuildTypeKHR

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

  4. -> MicromapBuildInfoEXT

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

  5. -> io ("sizeInfo" ::: MicromapBuildSizesInfoEXT)
#

vkGetMicromapBuildSizesEXT - Retrieve the required size for a micromap

Description

The dstMicromap, mode, data, scratchData, and triangleArray members of pBuildInfo are ignored by this command.

A micromap created with the micromapSize returned by this command supports any build with a MicromapBuildInfoEXT structure subject to the following properties:

Similarly, the buildScratchSize value will support any build command specifying the BUILD_MICROMAP_MODE_BUILD_EXT mode under the above conditions.

Valid Usage

Valid Usage (Implicit)

  • device must be a valid Device handle

See Also

VK_EXT_opacity_micromap, AccelerationStructureBuildTypeKHR, Device, MicromapBuildInfoEXT, MicromapBuildSizesInfoEXT

datadata MicromapBuildInfoEXT
#

VkMicromapBuildInfoEXT - Structure specifying the data used to build a micromap

Description

Only one of pUsageCounts or ppUsageCounts can be a valid pointer, the other must be NULL. The elements of the non-NULL array describe the total counts used to build each micromap. Each element contains a count which is the number of micromap triangles of that format and subdivisionLevel contained in the micromap. Multiple elements with the same format and subdivisionLevel are allowed and the total count for that format and subdivisionLevel is the sum of the count for each element.

Each micromap triangle refers to one element in triangleArray which contains the format and subdivisionLevel for that particular triangle as well as a dataOffset in bytes which is the location relative to data where that triangle’s micromap data begins. The data at triangleArray is laid out as a 4 byte unsigned integer for the dataOffset followed by a 2 byte unsigned integer for the subdivision level then a 2 byte unsigned integer for the format. In practice, compilers compile MicromapTriangleEXT to match this pattern.

For opacity micromaps, the data at data is packed as either one bit per element for OPACITY_MICROMAP_FORMAT_2_STATE_EXT or two bits per element for OPACITY_MICROMAP_FORMAT_4_STATE_EXT and is packed from LSB to MSB in each byte. The data at each index in those bytes is interpreted as discussed in Ray Opacity Micromap.

For displacement micromaps, the data at data is interpreted as discussed in Displacement Micromap Encoding.

Valid Usage

  • Only one of pUsageCounts or ppUsageCounts can be a valid pointer, the other must be NULL

Valid Usage (Implicit)

  • pNext must be NULL

  • type must be a valid MicromapTypeEXT value

  • flags must be a valid combination of BuildMicromapFlagBitsEXT values

  • If usageCountsCount is not 0, and pUsageCounts is not NULL, pUsageCounts must be a valid pointer to an array of usageCountsCount MicromapUsageEXT structures

  • If usageCountsCount is not 0, and ppUsageCounts is not NULL, ppUsageCounts must be a valid pointer to an array of usageCountsCount valid pointers to MicromapUsageEXT structures

See Also

VK_EXT_opacity_micromap, BuildMicromapFlagsEXT, BuildMicromapModeEXT, DeviceOrHostAddressConstKHR, DeviceOrHostAddressKHR, DeviceSize, MicromapEXT, MicromapTypeEXT, MicromapUsageEXT, StructureType, buildMicromapsEXT, cmdBuildMicromapsEXT, getMicromapBuildSizesEXT

Constructors

Instances3Show, ToCStruct, Zero

VkMicromapCreateInfoEXT - Structure specifying the parameters of a newly created micromap object

Description

If deviceAddress is zero, no specific address is requested.

If deviceAddress is not zero, deviceAddress must be an address retrieved from an identically created micromap on the same implementation. The micromap must also be placed on an identically created buffer and at the same offset.

Applications should avoid creating micromaps 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 and BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT to all buffers used as storage for a micromap with MICROMAP_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT_EXT included in createFlags. This also means that the tool will need to add MEMORY_ALLOCATE_DEVICE_ADDRESS_BIT to memory allocations to allow the 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 BUFFER_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT, to avoid address space allocation conflicts.

If the micromap will be the target of a build operation, the required size for a micromap can be queried with getMicromapBuildSizesEXT.

Valid Usage

Valid Usage (Implicit)

See Also

VK_EXT_opacity_micromap, Buffer, DeviceAddress, DeviceSize, MicromapCreateFlagsEXT, MicromapTypeEXT, StructureType, createMicromapEXT

Constructors

Instances6Eq, Show, Storable, FromCStruct, ToCStruct, Zero

VkMicromapVersionInfoEXT - Micromap 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 micromap that is loaded in memory. Using arrays would necessitate extra memory copies of the UUIDs.

Valid Usage (Implicit)

See Also

VK_EXT_opacity_micromap, StructureType, getDeviceMicromapCompatibilityEXT

Constructors

Instances4Show, FromCStruct, ToCStruct, Zero
datadata CopyMicromapInfoEXT
#

VkCopyMicromapInfoEXT - Parameters for copying a micromap

Valid Usage

Valid Usage (Implicit)

  • pNext must be NULL

  • src must be a valid MicromapEXT handle

  • dst must be a valid MicromapEXT handle

  • Both of dst, and src must have been created, allocated, or retrieved from the same Device

See Also

VK_EXT_opacity_micromap, CopyMicromapModeEXT, MicromapEXT, StructureType, cmdCopyMicromapEXT, copyMicromapEXT

Constructors

Instances6Eq, Show, Storable, FromCStruct, ToCStruct, Zero

VkCopyMicromapToMemoryInfoEXT - Parameters for serializing a micromap

Valid Usage

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

Valid Usage (Implicit)

See Also

VK_EXT_opacity_micromap, CopyMicromapModeEXT, DeviceOrHostAddressKHR, MicromapEXT, StructureType, cmdCopyMicromapToMemoryEXT, copyMicromapToMemoryEXT

Constructors

Instances3Show, ToCStruct, Zero

VkCopyMemoryToMicromapInfoEXT - Parameters for deserializing a micromap

Valid Usage

Valid Usage (Implicit)

See Also

VK_EXT_opacity_micromap, CopyMicromapModeEXT, DeviceOrHostAddressConstKHR, MicromapEXT, StructureType, cmdCopyMemoryToMicromapEXT, copyMemoryToMicromapEXT

Constructors

Instances3Show, ToCStruct, Zero

VkMicromapBuildSizesInfoEXT - Structure specifying build sizes for a micromap

Valid Usage (Implicit)

See Also

VK_EXT_opacity_micromap, Bool32, DeviceSize, StructureType, getMicromapBuildSizesEXT

Constructors

  • MicromapBuildSizesInfoEXT
    • micromapSize :: DeviceSize

      micromapSize is the size in bytes required in a MicromapEXT for a build or update operation.

    • buildScratchSize :: DeviceSize

      buildScratchSize is the size in bytes required in a scratch buffer for a build operation.

    • discardable :: Bool

      discardable indicates whether or not the micromap object may be destroyed after an acceleration structure build or update. A false value means that acceleration structures built with this micromap may contain references to the data contained therein, and the application must not destroy the micromap until ray traversal has concluded. A true value means that the information in the micromap will be copied by value into the acceleration structure, and the micromap can be destroyed after the acceleration structure build concludes.

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

VkMicromapUsageEXT - Structure specifying the usage information used to build a micromap

Description

The format is interpreted based on the type of the micromap using it.

See Also

VK_EXT_opacity_micromap, AccelerationStructureTrianglesDisplacementMicromapNV, AccelerationStructureTrianglesOpacityMicromapEXT, MicromapBuildInfoEXT

Constructors

Instances6Eq, Show, Storable, FromCStruct, ToCStruct, Zero

VkPhysicalDeviceOpacityMicromapFeaturesEXT - Structure describing the ray tracing opacity micromap features that can be supported by an implementation

Members

This structure describes the following feature:

Description

If the PhysicalDeviceOpacityMicromapFeaturesEXT 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 PhysicalDeviceOpacityMicromapFeaturesEXT, 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_EXT_opacity_micromap, Bool32, StructureType

Constructors

Instances6Eq, Show, Storable, FromCStruct, ToCStruct, Zero

VkPhysicalDeviceOpacityMicromapPropertiesEXT - Structure describing the opacity micromap properties of a physical device

Description

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

Structure Chaining

Extends the structure

See Also

VK_EXT_opacity_micromap, StructureType

Constructors

Instances6Eq, Show, Storable, FromCStruct, ToCStruct, Zero

VkAccelerationStructureTrianglesOpacityMicromapEXT - Structure specifying an opacity micromap in a bottom-level acceleration structure

Description

If AccelerationStructureTrianglesOpacityMicromapEXT is included in the pNext chain of a AccelerationStructureDenseGeometryFormatTrianglesDataAMDX or AccelerationStructureGeometryTrianglesDataKHR structure, that geometry will reference that micromap.

For each triangle in the geometry, the acceleration structure build fetches an index from indexBuffer using indexType and indexStride if present. If indexType is INDEX_TYPE_NONE_KHR, then the index used is the index of the triangle in the geometry.

If that value is the unsigned cast of one of the values from OpacityMicromapSpecialIndexEXT then that triangle behaves as described for that special value in Ray Opacity Micromap.

Otherwise that triangle uses the opacity micromap information from micromap at that index plus baseTriangle.

Only one of pUsageCounts or ppUsageCounts can be a valid pointer, the other must be NULL. The elements of the non-NULL array describe the total count used to build this geometry. For a given format and subdivisionLevel the number of triangles in this geometry matching those values after indirection and special index handling must be equal to the sum of matching count provided.

If micromap is NULL_HANDLE, then every value read from indexBuffer must be one of the values in OpacityMicromapSpecialIndexEXT.

Valid Usage

  • Only one of pUsageCounts or ppUsageCounts can be a valid pointer, the other must be NULL

Valid Usage (Implicit)

  • indexType must be a valid IndexType value

  • If usageCountsCount is not 0, and pUsageCounts is not NULL, pUsageCounts must be a valid pointer to an array of usageCountsCount MicromapUsageEXT structures

  • If usageCountsCount is not 0, and ppUsageCounts is not NULL, ppUsageCounts must be a valid pointer to an array of usageCountsCount valid pointers to MicromapUsageEXT structures

  • If micromap is not NULL_HANDLE, micromap must be a valid MicromapEXT handle

Structure Chaining

Extends the structures

See Also

VK_EXT_opacity_micromap, DeviceOrHostAddressConstKHR, DeviceSize, IndexType, MicromapEXT, MicromapUsageEXT, StructureType

Constructors

Instances3Show, ToCStruct, Zero
newtypenewtype MicromapTypeEXT
#

VkMicromapTypeEXT - Type of micromap

Description

See Also

VK_EXT_opacity_micromap, MicromapBuildInfoEXT, MicromapCreateInfoEXT

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

VkBuildMicromapFlagBitsEXT - Bitmask specifying additional parameters for micromap builds

Description

See Also

VK_EXT_opacity_micromap, BuildMicromapFlagsEXT

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

VkMicromapCreateFlagBitsEXT - Bitmask specifying additional creation parameters for micromap

Description

See Also

VK_EXT_opacity_micromap, MicromapCreateFlagsEXT

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

VkCopyMicromapModeEXT - Micromap copy mode

Description

  • COPY_MICROMAP_MODE_CLONE_EXT creates a direct copy of the micromap specified in src into the one specified by dst. The dst micromap must have been created with the same parameters as src.

See Also

VK_EXT_opacity_micromap, CopyMemoryToMicromapInfoEXT, CopyMicromapInfoEXT, CopyMicromapToMemoryInfoEXT

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

VkBuildMicromapModeEXT - Enum specifying the type of build operation to perform

Description

See Also

VK_EXT_opacity_micromap, MicromapBuildInfoEXT

Instances6Eq, Ord, Read, Show, Storable, Zero
newtypenewtype DeferredOperationKHR
#
Instances7Eq, Ord, Show, Storable, HasObjectType, IsHandle, …
newtypenewtype MicromapEXT
#
Instances7Eq, Ord, Show, Storable, HasObjectType, IsHandle, …
datadata MicromapTriangleKHR
#

VkMicromapTriangleKHR - Structure specifying the micromap format and data for a triangle

Description

The format is interpreted based on the type of the micromap using it.

See Also

VK_EXT_opacity_micromap, VK_KHR_opacity_micromap

Constructors

Instances6Eq, Show, Storable, FromCStruct, 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, …

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, …

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 OpacityMicromapFormatKHR
#

VkOpacityMicromapFormatKHR - Format enum for opacity micromaps

Description

For compactness, these values are stored as 16-bit in some structures.

See Also

VK_EXT_opacity_micromap, VK_KHR_opacity_micromap, MicromapUsageKHR

Instances6Eq, Ord, Read, Show, Storable, Zero

VkOpacityMicromapSpecialIndexKHR - Enum for special indices in the opacity micromap

Description

See Also

VK_EXT_opacity_micromap, VK_KHR_opacity_micromap

Instances6Eq, Ord, Read, Show, Storable, Zero