[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 https://github.com/microsoft/DirectXShaderCompiler/issues/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

[s-perron]

@ChristianReinbold Can you open a PR if you already have a patch? We just need some tests. We may get to this soon, but it could be faster if you open the PR.

[ChristianReinbold]

@s-perron See PR #7139. It is still lacking a test though. If you can give me a quick pointer to a test directory where I can reformulate my reproducer as a test, I will add it.

[NoSW]

I used the latest version(v1.8.2502, 2025_02_20) and had this bug (a mini test case #7300). What's confusing is that even the latest version of dxc can't compile ray tracing shader with -fspv-debug=vulkan-with-source , but the Nsight doc directly says

To enable function debug information in SPIRV, which is the dependency of Flame Graph, Top-Down Calls and Bottom-Up Calls, we need to add the argument -gVS (instead of -g) for glslangValidator or -fspv-debug=vulkan-with-source for dxc, to enable the SPIRV NonSemantic Shader DebugInfo extension.

How did they test it? 😢

[pborsutzki]

How did they test it? 😢

E.g. with Slang. Looks like Slang currently is Nvidias preferred shading language. Also, you don't need a raytracing shader to test callstacks, you can also just use a non-raytracing compute shader 😉

But for me, even with the patch from #7139 Nsight fails to show me callstacks - but for different reasons (it says it has no debug info at all).