[SPIR-V] Ray queries do not work with -fspv-debug=vulkan-with-source

[ChristianReinbold]

Description
When using ray queries together with -fspv-debug=vulkan-with-source, DXC crashes.

Steps to Reproduce
Find a reproducer here: https://godbolt.org/z/oxYerbYPP

Compile

[shader("raygeneration")]
void main() {
    RayQuery<RAY_FLAG_NONE> q;
}

with options -T lib_6_4 -spirv -fspv-target-env=vulkan1.2 -enable-16bit-types -HV 2021 -fspv-debug=vulkan-with-source.

After digging a bit in sources, to me the easiest fix seems to ensure that the spirv ray query type is lowered to an opaque debug type. The attached one-line patch debug_rayquery.patch should do this.

Environment
Recent version on godbolt.org: libdxcompiler.so: 1.8(dev;1-d39324e0); libdxil.so: 1.8

[devshgraphicsprogramming]

@keptsecret we usually compile with -fspv-debug=vulkan-with-source by default, why doesn't our ray query unit test crash as well?

We do have a significant difference that lib_6_x target never worked for us much and we use cs_

@ChristianReinbold curious question, why are you using ray-queries and RT pipeline at the same time?

[ChristianReinbold]

@devshgraphicsprogramming I always build my MWEs from a small snippet which used to be for the RT pipeline. I never updated the decorator and arguments though. When changing to compute shaders the problem still persists: https://godbolt.org/z/36PMMznKd

Did you double-check that you compile the unit test with the flag? I did not found a configuration nor any hint in the DXC code why ray queries could work with it.

[devshgraphicsprogramming]

Now we always tend to use Spir-V intrinsics because there's less problem/hassle for us than relying on the HLSL Spir-V codegen for certain "extensions"

Here's our custom Godbolt and STL library, it works and compiles
https://tinyurl.com/44fk3av7

You can clearly see

OpModuleProcessed "dxc-cl-option:  -T cs_6_7 -E main -spirv -Zpr -enable-16bit-types -fvk-use-scalar-layout -Wno-c++11-extensions -Wno-c++1z-extensions -Wno-c++14-extensions -Wno-gnu-static-float-init -fspv-target-env=vulkan1.3 -HV 202x -fspv-debug=source -fspv-debug=tool"

@keptsecret can you dig up the version that used HLSL intrinsic style RayQuery ?

[devshgraphicsprogramming]

@ChristianReinbold, huh -fspv-debug=vulkan-with-source segfaults, but -fspv-debug=source -fspv-debug=tool works... hmmm

[devshgraphicsprogramming]

OK, there's another similar issue #5113

The Non-Semantic Debug info extension was authored by the Renderdoc author, Renderdoc probably doesn't support ray-queries yet and definitely doesn't support RT pipeline shaders.

Because of the above, anything that renderdoc doesn't support/won't debug DXC probably never tested emitting vulkan-with-source debug info for, and even if it doesn't crash there's no telling its correct.

This leads to a question do other debuggers such as Nsight even require this extension to give you source level debug?

[ChristianReinbold]

#5113 seems to boil down to the same problem, just for another type missing in the switch statement.

Regarding usage: NSight Graphics also claims to require the option, see here (search for -fspv-debug=vulkan-with-source). This is what I am interested in.

[ChristianReinbold]

Regarding options source and tool: They behave differently than vulkan-with-source, see HLSLOptions.cpp:1213. As far as I see it, the flag that results in entering the broken code-path is opts.SpirvOptions.debugInfoRich = true.

It does not seem surprising that SpirV intrinsics work. I have not checked, but I would assume that DXC does not even try to generate some meaningful debug info for it.

[devshgraphicsprogramming]

#5113 seems to boil down to the same problem, just for another type missing in the switch statement.

Regarding usage: NSight Graphics also claims to require the option, see here (search for -fspv-debug=vulkan-with-source). This is what I am interested in.

Good to know that NSight debugs the same way.

[devshgraphicsprogramming]

Regarding options source and tool: They behave differently than vulkan-with-source, see HLSLOptions.cpp:1213. As far as I see it, the flag that results in entering the broken code-path is opts.SpirvOptions.debugInfoRich = true.

It does not seem surprising that SpirV intrinsics work. I have not checked, but I would assume that DXC does not even try to generate some meaningful debug info for it.

Actually seems like even with Spir-V intrinsics it will segfault.

[keptsecret]

@devshgraphicsprogramming @ChristianReinbold
Here's the version that used HLSL syntax ray query: https://tinyurl.com/44ycvrmu