[SPIR-V] Failed to compile raytracing shaders with "-fspv-debug=vulkan-with-source"

[maoenpei]

dxc crashes while compiling the following shader:

struct SceneConstants
{
	float4 eye;
	float4 U;
	float4 V;
	float4 W;
	float sceneScale;
};

RWTexture2D<float4> outputBuffer : register(u0);
RaytracingAccelerationStructure scene : register(t0);
ConstantBuffer<SceneConstants> sceneConstants : register(b0);

struct [raypayload] Payload
{
	float3 color;
	float t;
	int depth;
};

[shader("raygeneration")]
void RayGen()
{
	Payload payload;
	payload.color = float3(0,1,0);
	payload.t = 0;
	payload.depth = 0;

	float2 d = float2(DispatchRaysIndex().xy) / float2(DispatchRaysDimensions().xy) * 2.0f - 1.0f;
	RayDesc ray;
	ray.Origin = sceneConstants.eye.xyz;
	ray.Direction = normalize(d.x*sceneConstants.U.xyz + d.y*sceneConstants.V.xyz + sceneConstants.W.xyz);
	ray.TMin = 0;
	ray.TMax = 1e18;
	TraceRay( scene, RAY_FLAG_NONE, 0xff, 0, 1, 0, ray, payload );

	int2 idx = DispatchRaysIndex().xy;
	idx.y = DispatchRaysDimensions().y - idx.y - 1;
	outputBuffer[idx] = float4(payload.color.xyz,1);
}

My compiling command is:

dxc.exe -spirv -fspv-target-env=vulkan1.3 -T lib_6_7 -ERayGen dophin_HL.hlsl -Fo dophin.spv -no-warnings -fspv-debug=vulkan-with-source

And the result is:

Internal compiler error: access violation. Attempted to read from address 0x0000000000000008

If I delete option "-fspv-debug=vulkan-with-source", the compiling works.
If I delete this line "RaytracingAccelerationStructure scene : register(t0);" and the code that references "scene", the compiling works.

After I build dxc myself, I see there's a null pointer access without checking in EmitVisitor.cpp:

[Snowapril]

I've tracked a little bit why the debugType of the instruction became nullptr.
At DebugTypeVisitor::visitInstruction, the instruction's spirvType(kind : TK_AccelerationStructureNV) has never been matched by switch-case stmt in lowerToDebugType. Therefore lowerToDebugType returns nullptr for debugType of that instruction. There is no matching condition for TK_AccelerationStructureNV.
https://github.com/microsoft/DirectXShaderCompiler/blob/main/tools/clang/lib/SPIRV/DebugTypeVisitor.cpp#L412-L441

Would adding proper implementation for that type be the desired implementation? If this issue is triable for first contributing, I want to try it.

[maoenpei]

I've tracked a little bit why the debugType of the instruction became nullptr. At DebugTypeVisitor::visitInstruction, the instruction's spirvType(kind : TK_AccelerationStructureNV) has never been matched by switch-case stmt in lowerToDebugType. Therefore lowerToDebugType returns nullptr for debugType of that instruction. There is no matching condition for TK_AccelerationStructureNV. https://github.com/microsoft/DirectXShaderCompiler/blob/main/tools/clang/lib/SPIRV/DebugTypeVisitor.cpp#L412-L441

Would adding proper implementation for that type be the desired implementation? If this issue is triable for first contributing, I want to try it.

Hi @Snowapril, Just kindly ask if there's any progress for this issue? I'm not familiar with dxc implementation or the plan. It's just dxc is the only hope to compile raytracing shaders to SPIRV with debug information, as glslangValidator is even worse. :-p

[greg-lunarg]

@Snowapril @maoenpei -fspv-debug=vulkan-with-source for ray tracing shaders has not been tested a lot, partly due to the fact that renderdoc does not currently support source shader debugging for ray tracing. Why are you interested in compiling with -fspv-debug=vulkan-with-source?

[maoenpei]

@greg-lunarg I'm working on a developing tool (Nsight Graphics, similar to RenderDoc) that reflects the SPIRV <-> HLSL correlation. Recently we've added support of the "function scope" information for the shader. The first version only supports DXIL and now it's on SPIRV. There's a spec that clearly describes the non_semantic_info extension so the dxc bug doesn't block our work (coding, testing). But our tool cannot say the functionality is fully supported as long as dxc crashes.

I'll give you an example:

[s-perron]

@Snowapril If you believe you have a fix please contribute. I don't know when any of the maintainers will be able to get to it. As Greg said, there may be many more issue with ray tracing, so you might be opening up a much bigger issue. However, I am happy as long as we keep getting better.