Description
SPIR-V's equivalent for DXIL's RAYQUERY_FLAG_ALLOW_OPACITY_MICROMAPS on inline ray traces seems to be an execution mode with OpacityMicromapIdKHR 1 referencing an OpSpecConstantTrue (default-true spec constant). Is this something DXC can emit for us? It seems to be cumbersome to use https://github.com/microsoft/DirectXShaderCompiler/wiki/Inline-SPIR%E2%80%90V to emit a vk::ext_execution_mode_id(OpacityMicromapIdKHR, true) via a custom wrapper while still keeping the original constant working for DXIL.
And there's a further limitation linked there:
If using a lib_6_x target profile with multiple entry points, it will only be applied to one of them.
We have multiple entrypoints for RTPSO shaders that all use ray queries, so a possible workaround would need to apply to all of them.
And note that any shader containing OpExtension SPV_KHR_opacity_micromap in current DXC does not get properly deadstripped until the SPIRV-Tools submodule is updated to include KhronosGroup/SPIRV-Tools#6833.
Attributes on constants
As an aside I'd been quite happy to learn that extension and capability attributes can be applied on constants like so:
[[vk::ext_extension("SPV_KHR_opacity_micromap")]]
[[vk::ext_capability(RayTracingOpacityMicromapExecutionModeKHR)]]
static const uint OpacityMicromapIdKHR = 6031;But these are emitted in the final SPIR-V even if the constant itself is clearly never referenced: https://godbolt.org/z/xc3aPrvad
Is that intended?
Actual Behavior
No OpExecutionModeId OpacityMicromapIdKHR %true is emitted for RayQuery shaders with RAYQUERY_FLAG_ALLOW_OPACITY_MICROMAPS.
Likely complications live in the fact that this execution mode can be a spec constant, likely mimicking the host-settable behaviour for RTPSOs via VK_PIPELINE_CREATE_RAY_TRACING_OPACITY_MICROMAP_BIT_KHR. Unlike DXIL, SPIR-V users might want the ability to actually configure the spec constant instead of hardcoding it based on the presence of RAYQUERY_FLAG_ALLOW_OPACITY_MICROMAPS?
Environment
Description
SPIR-V's equivalent for DXIL's
RAYQUERY_FLAG_ALLOW_OPACITY_MICROMAPSon inline ray traces seems to be an execution mode withOpacityMicromapIdKHR1 referencing anOpSpecConstantTrue(default-truespec constant). Is this something DXC can emit for us? It seems to be cumbersome to use https://github.com/microsoft/DirectXShaderCompiler/wiki/Inline-SPIR%E2%80%90V to emit avk::ext_execution_mode_id(OpacityMicromapIdKHR, true)via a custom wrapper while still keeping the original constant working for DXIL.And there's a further limitation linked there:
We have multiple entrypoints for RTPSO shaders that all use ray queries, so a possible workaround would need to apply to all of them.
And note that any shader containing
OpExtension SPV_KHR_opacity_micromapin current DXC does not get properly deadstripped until the SPIRV-Tools submodule is updated to include KhronosGroup/SPIRV-Tools#6833.Attributes on constants
As an aside I'd been quite happy to learn that extension and capability attributes can be applied on constants like so:
But these are emitted in the final SPIR-V even if the constant itself is clearly never referenced: https://godbolt.org/z/xc3aPrvad
Is that intended?
Actual Behavior
No
OpExecutionModeId OpacityMicromapIdKHR %trueis emitted forRayQueryshaders withRAYQUERY_FLAG_ALLOW_OPACITY_MICROMAPS.Likely complications live in the fact that this execution mode can be a spec constant, likely mimicking the host-settable behaviour for RTPSOs via
VK_PIPELINE_CREATE_RAY_TRACING_OPACITY_MICROMAP_BIT_KHR. Unlike DXIL, SPIR-V users might want the ability to actually configure the spec constant instead of hardcoding it based on the presence ofRAYQUERY_FLAG_ALLOW_OPACITY_MICROMAPS?Environment
Footnotes
Using https://github.com/KhronosGroup/Vulkan-Docs/issues/2810 to clarify that this exclusively applies to inline ray tracing, while ray tracing pipelines use the
VK_PIPELINE_CREATE_RAY_TRACING_OPACITY_MICROMAP_BIT_KHRhost flag. Ray tracing pipeline shaders which perform inline ray queries with OMMs do need the execution mode though. ↩