The documentation for VK_KHR_opacity_micromap never states which kinds of traversal require the OpacityMicromapIdKHR execution mode, and we had to deduce it. The normative split is by traversal kind: VUID-vkCmdDispatch-micromap-11636 requires the execution mode for acceleration structure accesses through OpRayQueryProceedKHR, while VK_PIPELINE_CREATE_RAY_TRACING_OPACITY_MICROMAP_BIT_KHR is required for accesses that are not — and vkCmdTraceRaysKHR carries both VUIDs, so a ray tracing stage that itself issues ray queries needs both. GLSL_EXT_opacity_micromap_ray_query_mode says so outright ("applies only to ray query traversal and does not affect traversal initiated by traceRayEXT()"), glslang emits the mode on a ray generation entry point that issues a ray query, and the KHR conformance tests live in the ray query module. So the execution mode gates inline ray tracing only, and pipeline traversal keeps using the pipeline creation flag.
Three passages read as if it applied to all traversal and should be qualified accordingly. The Issues resolution of SPV_KHR_opacity_micromap, added in KhronosGroup/SPIRV-Registry#423, says "ray traversal" three times where the execution mode table in the same document says "ray query traversal". The promotion note in the VK_EXT_opacity_micromap appendix does the same, and that is exactly the text someone migrating from the EXT will read. And Ray Opacity Micromap reads as unconditional while mentioning neither opt-in, even though the same chapter spells out VK_PIPELINE_CREATE_RAY_TRACING_SKIP_TRIANGLES_BIT_KHR; a sentence there pointing at 11636 and 11640 would answer the question at the place a reader looks first.
While there, it would help to state whether the exemption in VUID-*-micromap-11636 is keyed on VK_EXT_opacity_micromap being enabled or on that extension's micromap feature, since vk.xml grants the RayTracingOpacityMicromapKHR capability from the extension alone with no feature bit set.
What is most confusing is that all of this is explained, but only in the proposal, down to the case we were unsure about: "If the VK_EXT_opacity_micromap extension is not enabled, this execution mode must be supplied to use opacity micromaps with ray queries, even if executed inside a ray pipeline shader with the VK_PIPELINE_CREATE_RAY_TRACING_OPACITY_MICROMAP_BIT_KHR flag specified." None of that survived into the extension appendix, which does not mention the execution mode at all beyond linking the GLSL extension, nor into the traversal chapter. Proposals are background documents rather than specification, so a clarification this load-bearing should not only live there — and the proposal also calls the mode OpacityMicromapKHR instead of OpacityMicromapIdKHR and writes gl_EnableOpacityMicromapExt instead of gl_EnableOpacityMicromapEXT.
The documentation for
VK_KHR_opacity_micromapnever states which kinds of traversal require theOpacityMicromapIdKHRexecution mode, and we had to deduce it. The normative split is by traversal kind: VUID-vkCmdDispatch-micromap-11636 requires the execution mode for acceleration structure accesses throughOpRayQueryProceedKHR, whileVK_PIPELINE_CREATE_RAY_TRACING_OPACITY_MICROMAP_BIT_KHRis required for accesses that are not — andvkCmdTraceRaysKHRcarries both VUIDs, so a ray tracing stage that itself issues ray queries needs both.GLSL_EXT_opacity_micromap_ray_query_modesays so outright ("applies only to ray query traversal and does not affect traversal initiated bytraceRayEXT()"), glslang emits the mode on a ray generation entry point that issues a ray query, and the KHR conformance tests live in the ray query module. So the execution mode gates inline ray tracing only, and pipeline traversal keeps using the pipeline creation flag.Three passages read as if it applied to all traversal and should be qualified accordingly. The Issues resolution of
SPV_KHR_opacity_micromap, added in KhronosGroup/SPIRV-Registry#423, says "ray traversal" three times where the execution mode table in the same document says "ray query traversal". The promotion note in theVK_EXT_opacity_micromapappendix does the same, and that is exactly the text someone migrating from the EXT will read. And Ray Opacity Micromap reads as unconditional while mentioning neither opt-in, even though the same chapter spells outVK_PIPELINE_CREATE_RAY_TRACING_SKIP_TRIANGLES_BIT_KHR; a sentence there pointing at 11636 and 11640 would answer the question at the place a reader looks first.While there, it would help to state whether the exemption in VUID-*-micromap-11636 is keyed on
VK_EXT_opacity_micromapbeing enabled or on that extension'smicromapfeature, sincevk.xmlgrants theRayTracingOpacityMicromapKHRcapability from the extension alone with no feature bit set.What is most confusing is that all of this is explained, but only in the proposal, down to the case we were unsure about: "If the
VK_EXT_opacity_micromapextension is not enabled, this execution mode must be supplied to use opacity micromaps with ray queries, even if executed inside a ray pipeline shader with theVK_PIPELINE_CREATE_RAY_TRACING_OPACITY_MICROMAP_BIT_KHRflag specified." None of that survived into the extension appendix, which does not mention the execution mode at all beyond linking the GLSL extension, nor into the traversal chapter. Proposals are background documents rather than specification, so a clarification this load-bearing should not only live there — and the proposal also calls the modeOpacityMicromapKHRinstead ofOpacityMicromapIdKHRand writesgl_EnableOpacityMicromapExtinstead ofgl_EnableOpacityMicromapEXT.