SPIR-V shader broken with compiler version > 1.7 - 1.6.0.3503

[YTN0]

I have a fairly standard vertex shader which is performing skinned animations.

I had previously been using DxC compiler version: dxcompiler.dll: 1.7 - 1.6.0.3503

Everything had been working fine with that compiler i.e. animations worked perfectly.

I upgraded to a more current version of the compiler (dxcompiler.dll: 1.7 - 1.7.0.3720), and now my shader is broken i.e. model / vertices are all messed up on screen.

I have double checked my code, and can't seem to find anything wrong with it. I also tried a couple other versions of the compiler (> 1.7 - 1.6.0.3503) and my shader seems to be broken in all of them. I have also tried many variations of flags, including turning on and off optimization with no changes in the outcome.

Both versions of the compiler are compiling the exact same code, except one works, and one does not.

I have included a disassembly of the output of both compiled SPIR-V files viz. working.txt and not-working.txt.

Would appreciate if someone more knowledgeable on the assembly could pinpoint what the issue might be (FYI, the assembly seems to deviate around line 356 in both files).

Thanks!

not-working.txt

working.txt

[vettoreldaniele]

Thanks for reporting. Can you please include the DXC compilation command you use to compile the shader?

EDIT: nevermind, I see they're included in the disassembly, sorry!

dxc skinned.vert -E main -T vs_6_7 -fspv-target-env=vulkan1.1 -spirv -Zi -Fo skinned.vert.spv -Qembed_debug

[vettoreldaniele]

I had a quick look, and while the generated code is slightly different, I wasn't able to immediately see what's actually different in behavior. The main difference I see is that the %out_var_TEXCOORD1 output is constructed all at once with a composite construct instead of doing a per-element insert starting with an undef (this also causes all operand numbers to be slightly shifted). Another difference is that many operations are moved closer to their use (many OpCompositeConstruct).

Can you confirm this is the shader causing the issue - if you compile the rest of the shaders with the old working version, and just this one with the newer version, is the problem still there? If this is confirmed to be the broken shader, we'll need to investigate further

[vettoreldaniele]

Also, can you please include the HLSL header files? It would make reproducing the exact compilation scenario easier.

[vettoreldaniele]

I've taken a more careful look. I've noticed that the matrices being loaded from the sbuffers buffer may be transposed in the non-working version.

Working:

         ; Load first 4 elements.
         %94 = OpAccessChain %_ptr_Uniform_uint %sbuffers %int_2 %uint_0 %93
         %95 = OpLoad %uint %94
         %96 = OpBitcast %float %95
         %97 = OpIAdd %uint %93 %uint_1
         %98 = OpAccessChain %_ptr_Uniform_uint %sbuffers %int_2 %uint_0 %97
         %99 = OpLoad %uint %98
        %100 = OpBitcast %float %99
         ...
        ; Construct first vector from the 4 elements
        %110 = OpCompositeConstruct %v4float %96 %100 %104 %108
         ...
        ; Load next 4 elements
        %111 = OpAccessChain %_ptr_Uniform_uint %sbuffers %int_2 %uint_0 %109
        %112 = OpLoad %uint %111
        %113 = OpBitcast %float %112
        %114 = OpIAdd %uint %93 %uint_5
        %115 = OpAccessChain %_ptr_Uniform_uint %sbuffers %int_2 %uint_0 %114
        %116 = OpLoad %uint %115
        %117 = OpBitcast %float %116
         ...
        ; Construct second vector from the 4 elements.
        %127 = OpCompositeConstruct %v4float %113 %117 %121 %125
         ...
        ; Load another 4 elements and construct the third vector, then load the last 4 elements and construct the fourth vector
        %144 = OpCompositeConstruct %v4float %130 %134 %138 %142
        %160 = OpCompositeConstruct %v4float %147 %151 %155 %159
        ; Construct the matrix from the vectors
        %161 = OpCompositeConstruct %mat4v4float %110 %127 %144 %160

Non-working:

        ; Load all 16 elements first.
        %311 = OpShiftRightLogical %uint %310 %uint_2
        %312 = OpAccessChain %_ptr_Uniform_uint %sbuffers %int_2 %uint_0 %311
        %313 = OpLoad %uint %312
        %314 = OpBitcast %float %313
        %315 = OpIAdd %uint %311 %uint_1
        %316 = OpAccessChain %_ptr_Uniform_uint %sbuffers %int_2 %uint_0 %315
        %317 = OpLoad %uint %316
        %318 = OpBitcast %float %317
        ...
        ; Construct the 4 vectors. Here the first 4 elements (%314, %318, %322, %326) are in columns, not in rows.
        %375 = OpCompositeConstruct %v4float %314 %330 %346 %362
        %376 = OpCompositeConstruct %v4float %318 %334 %350 %366
        %377 = OpCompositeConstruct %v4float %322 %338 %354 %370
        %378 = OpCompositeConstruct %v4float %326 %342 %358 %374

This may be related to #4526, which addresses load semantics for byte buffers. Here, the buffer is a ByteAddressBuffer

[vettoreldaniele]

@YTN0 Can you try compiling the shader with -fspv-use-legacy-buffer-matrix-order and seeing if that solves the issue?

[YTN0]

@vettoreldaniele Appreciate you looking into this. Looks like when I compile with the -fspv-use-legacy-buffer-matrix-order flag, that fixes the problem!

That led me to look at my skinning code again, and it seems like I did not transpose the joint matrices before sending to the shader. I believe I was doing that at some point, but I removed it since it was not working with that version of the shader compiler.

It's likely that the earlier version of the compiler (where this code does work) has a bug which for some weird reason caused this to work, and that got fixed in a more recent build, which then broke the shader.

Thanks again for diving into this!