Closed csyonghe closed 5 months ago
The construction of using DebugValue
to index into a vector and using OpAccessChain
through a pointer to a structure member to modify the y-component is not currently handled by the RenderDoc source level debugging.
Source
t.memberB = float3(1, 2, 3);
t.memberB.y = 4.0;
SPIRV slang
%167 = OpAccessChain %_ptr_Function_v3float %t %int_1
OpStore %167 %168
%175 = OpAccessChain %_ptr_Function_float %167 %int_1
OpStore %175 %float_4
For reference: SPIRV glslang
construction which does work with RenderDoc source debugging
%86 = OpAccessChain %_ptr_Function_v3float %t %int_1
OpStore %86 %84
%89 = OpAccessChain %_ptr_Function_float %t %int_1 %uint_1
OpStore %89 %float_4
The difference with glslang and slang's own spirv backend (enabled with -emit-spirv-directly
in slangc
) is that Slang uses more SSA registers than explicit OpVar
s and is relying on OpDebugValue
to update a debug variable. Therefore we don't use OpDebugDeclare
to link a debug variable with an actual variable as done in glslang, but rely more heavily on OpDebugValue
.
Description
When debugging SPIRV shader that uses
OpDebugValue
to update an element of aOpDebugTypeVector
debug variable, the variable value does not change in the debug watch window.Steps to reproduce
repro.zip
vkCmdDispatch
command from event browser.t.memberB
to have updated vector value, but it is not updated.Environment