Unable to find suitable #line directive in SPIR-V source

[DethRaid]

Environment:

• OS: Windows 11
• GPU: RTX 2080 Super
• SDK or header version if building from repo: 1.3.243.0
• Options enabled (synchronization, best practices, etc.): Synchronization, GPU-assisted validation

Describe the Issue

GPU assisted validation reports a shader file name and line, but this line is incorrect. It also reports that it's unable to find a suitable line directive in my shader

Expected behavior

GPU assisted validation should either report a correct shader file name and line, or it should report that it's unable to determine the correct shader file name or line

Valid Usage ID Validation Error: [ UNASSIGNED-Descriptor uninitialized ] Object 0: handle = 0x1954061ece0, name = Graphics queue, type = VK_OBJECT_TYPE_QUEUE; | MessageID = 0x893513c7 | Descriptor index 1 is uninitialized. Command buffer (0x19555250b40). Compute Dispatch Index 0x2. Pipeline (Inject into GV)(0x67022e000000004b). Shader Module (0x7323f50000000048). Shader Instruction Index = 379. Stage = Compute. Global invocation ID (x, y, z) = (1, 3, 0 ) Shader validation error occurred in file D:/Source/SahRenderer/Windows/../RenderCore/shaders/lpv/inject_into_gv.comp at line 78.Unable to find suitable #line directive in SPIR-V OpSource.

Additional context

I have some problem in my shader. I enabled GPU assisted validation to help debug it. I received the above message

I don't know how to interpret it. It reports that the shader validation error occurred in a certain line of a certain file, but then it immediately states that it's unable to find a suitable line directive. There's no space before that last sentence - is this a bug with how the message is being output?

If GPU assisted validation is able to determine the shader file and line where the error occurred, why does it report that it's unable to find a suitable line directive? If it's not able to determine where the error occurred, why does it report a shader file and line? The whole thing is very confusing

[juan-lunarg]

Can you provide a SSCCE of the shader in question?

NOTE: We don't need your actual shader. Just a shader that can reproduce the issue.

[TonyBarbour]

If it could have found a #line directive in the SPIR-V OpSource, it would have printed the line of source code where it detected the error. I'd agree that the message could be clearer.

[DethRaid]

Did it not print out the line of the source code where it found the error? e.g. Shader validation error occurred in file D:/Source/SahRenderer/Windows/../RenderCore/shaders/lpv/inject_into_gv.comp at line 78.

I can share the actual shader. GLSL and SPIR-V are in this zip inject_into_gv.zip

This particular error happened when I only bound one descriptor to the descriptor array at set=0 binding=4, but tried to access descriptor index 1

[DethRaid]

I've seen this issue with a few of my shaders. I compile them with glslangValidator, with the options --target-env vulkan1.3 -g -Od and options for my include paths

[SaschaWillems]

I'm seeing a similar layer error when using GPU assisted validation in a sample that uses descriptor buffers. Is it possible that this is a false positive when using VK_EXT_descriptor_buffer?

[TonyBarbour]

The "Unable to find suitable #line directive in SPIR-V OpSource" issue is due to the command line behavior of glslang changing and it no longer inserts a #line directive in the shader source. The C interface glslang still does, which was why our testing didn't detect this.

[TonyBarbour]

I don't think GPU-AV works with descriptor buffers, so a false positive would not be surprising. We are working on it though.

[DethRaid]

Interesting

Looks like I can change my glslangValidator command line to -gVS to get it to generate shaders will full debug information?

But if I do that, it fails to compile some of my shaders. There's no error message or anything, it just prints out the name of the shader. I guess I'm stuck using -g

I'd still like for the error messages from the validation layers to either state the file and line where the error occurred, or to state that they can't determine the file or line where the error occurred. The current messages are just confusing

[TonyBarbour]

I plan to fix the behavior without #line directives - tracking it with this issue And the error message And GPU-AV has not been updated to process -gVS output. It is on the to-do list

[spencer-lunarg]

I have gone through and did a lot of cleanup for this and added tests and we should now be catching any OpLine/OpSource and displaying it in the output of GPU-AV and/or DebugPrintF (verbose)

There is still a gap for people using NonSemantic.Shader.DebugInfo.100, but that should be in soon

if issues arise were you are not seeing debug info (and you should/want) in your error messages, please raise a new issue and I will take a look at it ASAP!