dEQP-VK.graphicsfuzz.modf-temp-modf-color about llpc

[kuhar]

Not whether this input spv is valid.

The crash happens when translating the last OpExtInst:

               OpCapability Shader
          %1 = OpExtInstImport "GLSL.std.450"
               OpMemoryModel Logical GLSL450
               OpEntryPoint Fragment %main "main" %_GLF_color
               OpExecutionMode %main OriginUpperLeft
               OpSource ESSL 310
               OpName %main "main"
               OpName %temp "temp"
               OpName %_GLF_color "_GLF_color"
               OpDecorate %_GLF_color Location 0
       %void = OpTypeVoid
          %6 = OpTypeFunction %void
      %float = OpTypeFloat 32
    %v4float = OpTypeVector %float 4
    %float_1 = OpConstant %float 1
         %10 = OpConstantComposite %v4float %float_1 %float_1 %float_1 %float_1
%_ptr_Function_v4float = OpTypePointer Function %v4float
    %float_0 = OpConstant %float 0
         %13 = OpConstantComposite %v4float %float_1 %float_0 %float_0 %float_1
                  ...
         %17 = OpExtInst %v4float %1 Modf %13 %_GLF_color     <====
               OpReturn
               OpFunctionEnd

The second argument to Modf is in address space 65, instead of 5. Due to type mismatch

This seems similar to the issue reported here: KhronosGroup/SPIRV-Cross#1123.

If the input spv is valid, would it be enough to just introduce an address space cast before passing the %_GLF_color to Modf?

[trenouf]

I wonder if this is fixed by my outstanding PR #169, which reimplements Modf with a separate ModfStruct and store in the spir-v reader.

I guess the problem at the moment might be that the modf is a library function, so it eventually expands to have a store, but not in time for LowerGlobal to spot that it is a store to an output.

[MarcinKantochAMD]

I ran the test today and it is passing on our LLPC stack.

[MarcinKantochAMD]

Sorry Paul. I was not aware that your issues relate to Debug build. I was testing with a Release build.

[paulthomson]

Appears to be fixed!