Regression: incorrect warnings claiming shaders aren't writing to attachments beyond the first one.

[mbechard]

Environment:

• OS: Windows 10
• GPU and driver version: Quadro 6000 Ada, 522.22
• SDK or header version if building from repo: 1.3.280.0
• Options enabled (synchronization, best practices, etc.):

Describe the Issue

Starting in SDK 1.3.275.0 (and not occurring in 1.3.268.0) I now get incorrect validation warnings for attachments that the validation thinks aren't getting written by shaders.

WARNING : VALIDATION - Message Id Number: 1203141749 | Message Id Name: Undefined-Value-ShaderInputNotProduced
        Validation Warning: [ Undefined-Value-ShaderInputNotProduced ] Object 0: handle = 0xf39fcf00000020fb, type = VK_OBJECT_TYPE_SHADER_MODULE; | MessageID = 0x47b67c75 | vkCreateGraphicsPipelines(): pCreateInfos[0] Attachment 1 not written by fragment shader; undefined values will be written to attachment

The below simple shader will produce the warning

                              SourceExtension  "GL_EXT_nonuniform_qualifier"
                              SourceExtension  "GL_EXT_scalar_block_layout"
                              SourceExtension  "GL_GOOGLE_cpp_style_line_directive"
                              SourceExtension  "GL_GOOGLE_include_directive"
                              Name 10  "main"
                              Name 29  "fragColor"
                              ModuleProcessed  "auto-map-bindings"
                              ModuleProcessed  "auto-map-locations"
                              ModuleProcessed  "client vulkan100"
                              ModuleProcessed  "target-env spirv1.3"
                              ModuleProcessed  "target-env vulkan1.1"
                              ModuleProcessed  "entry-point main"
                              ModuleProcessed  "client vulkan100"
                              ModuleProcessed  "target-env spirv1.3"
                              ModuleProcessed  "target-env vulkan1.1"
                              ModuleProcessed  "entry-point main"
                              Decorate 29(fragColor) Location 0
               8:             TypeVoid
               9:             TypeFunction 8
              12:             TypeFloat 32
              13:             TypeVector 12(float) 4
              23:   12(float) Constant 1065353216
              24:   13(fvec4) ConstantComposite 23 23 23 23
              25:             TypeInt 32 0
              26:     25(int) Constant 2
              27:             TypeArray 13(fvec4) 26
              28:             TypePointer Output 27
   29(fragColor):     28(ptr) Variable Output
              30:             TypeInt 32 1
              31:     30(int) Constant 0
              35:             TypePointer Output 13(fvec4)
              37:     30(int) Constant 1
                              Line 1 6 11
        10(main):           8 Function None 9
                              NoLine
              11:             Label
                              Line 1 9 0
              36:     35(ptr) AccessChain 29(fragColor) 31
                              Store 36 24
                              Line 1 10 0
              41:     35(ptr) AccessChain 29(fragColor) 37
                              Store 41 24
                              Return
                              FunctionEnd

Expected behavior

This isn't an warning, the shader is correctly writing to that attachment.

Valid Usage ID

WARNING : VALIDATION - Message Id Number: 1203141749 | Message Id Name: Undefined-Value-ShaderInputNotProduced
        Validation Warning: [ Undefined-Value-ShaderInputNotProduced ] Object 0: handle = 0xf39fcf00000020fb, type = VK_OBJECT_TYPE_SHADER_MODULE; | MessageID = 0x47b67c75 | vkCreateGraphicsPipelines(): pCreateInfos[0] Attachment 1 not written by fragment shader; undefined values will be written to attachment

[spencer-lunarg]

So taking a look into this, the whole logic seemed messed up and needs more testing. Thanks for pointing this out

[Reedbeta]

My team has just run into this as well. It looks to me like the same basic issue: in our GLSL we define an array of outputs, like

layout(location = 0) out vec4 out_aovs[AOV_COUNT];

and then we get warnings for attachments 1 and up, although they're all written by the shader. In our case we also loop over the outputs to write them, which I suspect will complicate the validation analysis, unfortunately.

[spencer-lunarg]

Patch was added for the next SDK to not give false positive for arrays of fragment output, will find more time later to re-do the logic as there are many missing edge cases and just an overall lack of testing for the Fragment output interface checks from what I see