Add ALLOW_OPACITY_MICROMAPS template flag to RayQuery object

[amarpMSFT]

Inline raytracing needs to be aware OMMs may be used, just like non-inline raytracing does.

Non-inline raytracing has RAYTRACING_PIPELINE_FLAG_ALLOW_OPACITY_MICROMAPS.

But raytracing pipeline state doesn't apply to inline raytracing. So for in the inline case, add a RAYQUERY_FLAG_ALLOW_OPACITY_MICROMAPS flag to the template parameters for instantiating the RayQuery object.

[damyanp]

@amarpMSFT - sorry for the delay here. Does adding this new template flag to the RayQuery object mean we also need to add new diagnostics, or make any changes to DXIL? If so, then this also needs to be detailed in the proposal.

[amarpMSFT]

@amarpMSFT - sorry for the delay here. Does adding this new template flag to the RayQuery object mean we also need to add new diagnostics, or make any changes to DXIL? If so, then this also needs to be detailed in the proposal.

My guess is it would. If HLSL folks can confirm this solution is something you're ok with, the same folks might be able to quickly summarize the necessary DXIL/diag changes. But if not, I can take a stab.

[tex3d]

@amarpMSFT - sorry for the delay here. Does adding this new template flag to the RayQuery object mean we also need to add new diagnostics, or make any changes to DXIL? If so, then this also needs to be detailed in the proposal.

My guess is it would. If HLSL folks can confirm this solution is something you're ok with, the same folks might be able to quickly summarize the necessary DXIL/diag changes. But if not, I can take a stab.

After sorting out some questions:

• Is SM 6.9 the only requirement, or is there an optional feature bit we need to introduce? With the DXR pipeline, we could detect feature usage from the subobject flag or use of the equivalent flag in the API. For RayQuery we don't have that luxury, so we may need an optional feature flag to indicate use in the shader.
• Do we need additional runtime info (RDAT, PSV0) to indicate a usage with a RaytracingAccelerationStructure resource? Maybe this will be nothing because we would rely on GBV only for these checks.

This will require additions in:

• AllocateRayQuery DXIL op
• updated diagnostic requirements
• validation changes
• potential new feature info flag and/or additional runtime info (RDAT, PSV0) required for runtime checks
• research/comment on SPIR-V alignment
• various test additions