[SPIR-V] DXC emits OpCapability RayQueryKHR even when not requested

[natevm]

I'm running into an unfortunate bug where DXC requests RayQueryKHR even when ray queries are never used.

This is an issue, because NVIDIA cards without RT cores using their software fallback do not support ray queries.

As a consequence, no ray tracing shaders compiled by DXC are compatible with GTX cards or NVIDIA cards like the A100 without RT cores.

Further, we get incorrect compilation errors stating generated SPIR-V is invalid: 1st operand of Capability: operand RayQueryKHR(4472) requires one of these extensions: SPV_KHR_ray_query

[natevm]

I believe it was this pull request that caused this regression.

#4151

[natevm]

Here's the A100 GPU in question. We want to use these A100s with Vulkan at ANL on our Polaris supercomputer
https://vulkan.gpuinfo.org/displayreport.php?id=21882#extensions

If you look at this extension survey, VK_KHR_ray_tracing has more coverage than VK_KHR_ray_query, so the assumption made by @sudonatalie in PR #4151 is not true.

https://vulkan.gpuinfo.org/listextensions.php

We also have some issues reported by end users of DXC, eg @ashpil, that this is causing incompatibilities with Pascal cards like their GTX 1080.

[natevm]

This is the logic that I'd propose we revert or change. The original author of this PR suggested a spirv-opt pass. I'm not sure that's such a good idea, since then we're dependent on spirv-opt to add more tooling rather than addressing the issue here.

ce31e10#diff-44e37c9720575ff94b7842b9ceb70a87fe72486d2b5da2e3828512dc64a352e6R217-R222

[natevm]

@ashpil In retrospect, it seems that the ray query extension is only really added if you have both a non-RT-pipeline entrypoint in the same file that a RaytracingAccelerationStructure handle is used. So, the current behavior in DXC might be right actually...

Wondering how you're running into this issue... My circumstances are a bit unique.

[Keenuts]

Hello!

Just FYI, I think this new spirv-opt pass will solve this issue (KhronosGroup/SPIRV-Tools#5278).

The original author of this PR suggested a spirv-opt pass. I'm not sure that's such a good idea, since then we're dependent on spirv-opt to add more tooling rather than addressing the issue here.

DXC uses spirv-opt already. Adding it as a new pass is transparent for you.

The main idea is to solve an issue we already have which is that capabilities do not reflect the optimized code, but the parsed AST.

This is because DXC generates SPIR-V in 3 steps:

• AST generated from HLSL
• DXC generates the non-optimized SPIR-V + capabilities from the AST
• DXC calls spirv-opt for the given code

Optimization being done after adding capabilities means we generate capabilities for the non-optimized/non-trimmed code.
Spirv-opt doesn't have a capability-fixing pass.
Adding a new pass to trim capabilities (and linked extensions) should solve this issue.

[s-perron]

This is a duplicate of #4795 in a general way. I'll close this a duplicate. We are currently working on it.

[natevm]

I did run into this issue again this morning, this feature will be very appreciated 🙏

[natevm]

This is a duplicate of #4795 in a general way. I'll close this a duplicate. We are currently working on it.

Looks like although this issue might have gone stale. There was a merged PR that was mentioned in this issue as the first phase. Wondering what the next steps are to addressing this bug.

[ashpil]

Should this be fixed now? Doesn't appear to be on my machine (with this shader).