1// Copyright (c) 2022 The Khronos Group Inc. 2// 3// SPDX-License-Identifier: CC-BY-4.0 4 5include::{generated}/meta/{refprefix}VK_EXT_opacity_micromap.adoc[] 6 7=== Other Extension Metadata 8 9*Last Modified Date*:: 10 2022-08-24 11*Interactions and External Dependencies*:: 12 - This extension requires 13 {spirv}/EXT/SPV_EXT_opacity_micromap.html[`SPV_EXT_opacity_micromap`] 14 - This extension provides API support for 15 {GLSLregistry}/ext/GLSL_EXT_opacity_micromap.txt[`GLSL_EXT_opacity_micromap`] 16*Contributors*:: 17 - Christoph Kubisch, NVIDIA 18 - Eric Werness, NVIDIA 19 - Josh Barczak, Intel 20 - Stu Smith, AMD 21 22=== Description 23 24When adding adding transparency to a ray traced scene, an application can 25choose between further tessellating the geometry or using an any hit shader 26to allow the ray through specific parts of the geometry. 27These options have the downside of either significantly increasing memory 28consumption or adding runtime overhead to run shader code in the middle of 29traversal, respectively. 30 31This extension adds the ability to add an _opacity micromap_ to geometry 32when building an acceleration structure. 33The opacity micromap compactly encodes opacity information which can be read 34by the implementation to mark parts of triangles as opaque or transparent. 35The format is externally visible to allow the application to compress its 36internal geometry and surface representations into the compressed format 37ahead of time. 38The compressed format subdivides each triangle into a set of subtriangles, 39each of which can be assigned either two or four opacity values. 40These opacity values can control if a ray hitting that subtriangle is 41treated as an opaque hit, complete miss, or possible hit, depending on the 42controls described in <<ray-opacity-micromap,Ray Opacity Micromap>>. 43 44This extension provides: 45 46 * a slink:VkMicromapEXT structure to store the micromap, 47 * functions similar to acceleration structure build functions to build the 48 opacity micromap array, and 49 * a structure to extend 50 slink:VkAccelerationStructureGeometryTrianglesDataKHR to attach a 51 micromap to the geometry of the acceleration structure. 52 53include::{generated}/interfaces/VK_EXT_opacity_micromap.adoc[] 54 55=== Reference code 56[source,c++] 57---------------------------------------- 58uint32_t BarycentricsToSpaceFillingCurveIndex(float u, float v, uint32_t level) 59{ 60 u = clamp(u, 0.0f, 1.0f); 61 v = clamp(v, 0.0f, 1.0f); 62 63 uint32_t iu, iv, iw; 64 65 // Quantize barycentric coordinates 66 float fu = u * (1u << level); 67 float fv = v * (1u << level); 68 69 iu = (uint32_t)fu; 70 iv = (uint32_t)fv; 71 72 float uf = fu - float(iu); 73 float vf = fv - float(iv); 74 75 if (iu >= (1u << level)) iu = (1u << level) - 1u; 76 if (iv >= (1u << level)) iv = (1u << level) - 1u; 77 78 uint32_t iuv = iu + iv; 79 80 if (iuv >= (1u << level)) 81 iu -= iuv - (1u << level) + 1u; 82 83 iw = ~(iu + iv); 84 85 if (uf + vf >= 1.0f && iuv < (1u << level) - 1u) --iw; 86 87 uint32_t b0 = ~(iu ^ iw); 88 b0 &= ((1u << level) - 1u); 89 uint32_t t = (iu ^ iv) & b0; 90 91 uint32_t f = t; 92 f ^= f >> 1u; 93 f ^= f >> 2u; 94 f ^= f >> 4u; 95 f ^= f >> 8u; 96 uint32_t b1 = ((f ^ iu) & ~b0) | t; 97 98 // Interleave bits 99 b0 = (b0 | (b0 << 8u)) & 0x00ff00ffu; 100 b0 = (b0 | (b0 << 4u)) & 0x0f0f0f0fu; 101 b0 = (b0 | (b0 << 2u)) & 0x33333333u; 102 b0 = (b0 | (b0 << 1u)) & 0x55555555u; 103 b1 = (b1 | (b1 << 8u)) & 0x00ff00ffu; 104 b1 = (b1 | (b1 << 4u)) & 0x0f0f0f0fu; 105 b1 = (b1 | (b1 << 2u)) & 0x33333333u; 106 b1 = (b1 | (b1 << 1u)) & 0x55555555u; 107 108 return b0 | (b1 << 1u); 109} 110---------------------------------------- 111 112=== Issues 113 114(1) Is the build actually similar to an acceleration structure build? 115-- 116 * Resolved: The build should be much lighter-weight than an acceleration 117 structure build, but the infrastructure is similar enough that it makes 118 sense to keep the concepts compatible. 119-- 120 121(2) Why does VkMicromapUsageEXT not have type/pNext? 122-- 123 * Resolved: There can be a very large number of these structures, so 124 doubling the size of these can be significant memory consumption. 125 Also, an application may be loading these directly from a file which is 126 more compatible with it being a flat structure. 127 The including structures are extensible and are probably a more suitable 128 place to add extensibility. 129-- 130 131(3) Why is there a SPIR-V extension? 132-- 133 * Resolved: There is a ray flag. 134 To be consistent with how the existing ray tracing extensions work that 135 ray flag needs its own extension. 136-- 137 138(4) Should there be indirect micromap build? 139-- 140 * Resolved: Not for now. 141 There is more in-depth usage metadata required and it seems less likely 142 that something like a GPU culling system would need to change the counts 143 for a micromap. 144-- 145 146(5) Should micromaps have a micromap device address? 147-- 148 * Resolved: There is no need right now (can just use the handle) but that 149 is a bit different from acceleration structures, though the two are not 150 completely parallel in their usage. 151-- 152 153(6) Why are the alignment requirements defined as a mix of hardcoded values 154and caps? 155-- 156 * Resolved: This is most parallel with the definition of 157 `apiext:VK_KHR_acceleration_structure` and maintaining commonality makes 158 it easier for applications to share memory. 159-- 160 161=== Version History 162 163 * Revision 2, 2022-06-22 (Eric Werness) 164 ** EXTify and clean up for discussion 165 * Revision 1, 2022-01-01 (Eric Werness) 166 ** Initial revision 167