[Bug 49186] DXBC compiler generates incorrect spir-v code

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=49186

--- Comment #3 from Henri Verbeet  ---
(In reply to Alex from comment #2)
> The patch doesn't help, although I didn't look at the produced shader binary.

I'm afraid I may need some more context on what you're trying to do in order to
reproduce the issue then. For what it's worth:

The issue the patch addresses is the following (from spirv-val):

error: line 130: OpAccessChain result type (OpTypeVector) does not match
the type that results from indexing into the base <id> (OpTypeFloat).
      %52 = OpAccessChain %_ptr_Input_v4float %v1 %51

That happens because of the following bits in the .fxc:

// Input signature:
    [...]
    // SV_CLIPDISTANCE          0   xyzw        1  CLIPDST   float
    [...]
    dcl_input v[5][1].xyzw
    [...]
    mov o1.xyzw, v[r0.x + 0][1].xyzw

v1 is a vec4 bound to SV_CLIPDISTANCE in the .fxc, but SpvBuiltInClipDistance
is a scalar. The patch handles that difference by filling the additional
components (.yzw) with zeroes; it may need to replicate the .x component
instead, that's the part that needs tests.

It's not entirely clear to me how you produced the quoted GLSL. You mention
spirv-dis, but at least the version I have here doesn't appear to have that
feature. (But, it's also more than two weeks old...) I know spirv-cross can
turn SPIR-V into GLSL, is that perhaps what you used?

In any case, the following line in the quoted GLSL appears to have been
incorrectly translated from the SPIR-V:

out float gl_ClipDistance[5];

Specifically, the "out" there. From the SPIR-V:

OpDecorate %v1 BuiltIn ClipDistance
    [...]
    %v1 = OpVariable %_ptr_Input__arr_float_uint_5 Input

ClipDistance is used as an input, not an output.
> Perhaps those error messages are relevant:
>
> fixme:vkd3d_dxbc_compiler_check_index_range: Unhandled index range write
> mask 0x1 (0xf).
> fixme:vkd3d_dxbc_compiler_emit_dcl_index_range: Ignoring dcl_index_range 0x6
> 2.

That's from this line in the .fxc:

dcl_indexrange o0.x 2

In context:

hs_fork_phase 
    dcl_hs_fork_phase_instance_count 2
    dcl_input vForkInstanceID
    dcl_output_siv o0.x, finalTriUeq0EdgeTessFactor
    dcl_output_siv o1.x, finalTriVeq0EdgeTessFactor
    dcl_temps 1
    dcl_indexrange o0.x 2
    mov r0.x, vForkInstanceID.x
    mov o[r0.x + 0].x, l(1.000000)
    ret

We should of course fix that, but it seems unlikely to be consequential for the
purposes of this bug report.