Use NonSemantic info and other source debug information to map SPIR-V Validation errors to original source

[devshgraphicsprogramming]

Producers of SPIR-V can often emit invalid SPIR-V, and sometimes even on purpose (DXC).

During the development of a Compiler outputting SPIR-V bugs will be made, when users file bugreports we often ask for a minimally reproducible example.

Someone without a debug build of said compiler may never see the SPIR-V emitted being fed into SPIR-V Tools, and even if they do they'll have a hard time mapping the line of SPIR-V disassembly and the SSA Result ID that the SPIR-V Validator complains about back to their own source code.

Even for compiler developers this would greatly improve the workflow

I'd propose to use the existing embedded source information and non-semantic information (if the producer emits them) to also display are least the file name, function name and line of the function that generated the offending instructions.

Even better if we could show a range of source lines.

The SPIR-V Visualizer is already able to show the expression trees of operands (and their own trees) involved in an Operation or which produced an SSA ResultID, a full trace of source could be printed, similar to a C++ template instantiation error.

[devshgraphicsprogramming]

Actually Godbolt's Compiler Explorer is already able to display more or less which bits of SPIR-V map to which bit of HLSL, so maybe its possible to build on whatever its doing for all languages.

[Firestar99]

Rust-GPU has an open feature request where someone specifically requested us to map spirv-val errors to rust source code, since we have the source file and line information already. So there's definitely a demand for this from developers.
Rust-GPU/rust-gpu#323

[spencer-lunarg]

In theory, I assume this would work how GPU-AV (inside Vulkan-Validation Layers) does it

We have a set of functions (done without any helper classes) that will search for the last OpLine or ShaderDebugInfo100DebugLine and use that to map the line the error message occured

https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob/e6394a8bfd66a8319d35befe0b5380bd807c63d4/layers/error_message/spirv_logging.cpp#L330

For OpType* and OpVariable level errors (things outside the function), it might get harder as even the ShaderDebugInfo doesn't always have information

But I agree, if there is source information, I think even people getting spirv-val level errors in VVL would benefit (so basically nerd sniping myself here)

[spencer-lunarg]

@devshgraphicsprogramming I have an implementation up in #6648 using ShaderDebugInfo

currently prints out an error message like

error: 34: OpAccessChain reached non-composite type while indexes still remain to be traversed.
  %25 = OpAccessChain %_ptr_StorageBuffer_v4float %6 %int_0 %int_0 %int_0

Source file "a.comp" at line 7

    data = vec4(0.0);

or

error: 35: OpAccessChain reached non-composite type while indexes still remain to be traversed.
  %26 = OpAccessChain %_ptr_StorageBuffer_v4float %6 %int_0 %int_0 %int_0

Source file "a.comp" at line 6-8

void main() {
    data = vec4(0.0);
}

feedback/input is highly welcomed

I plan this to be multiple passes, first is just adding a line number, next would be if there is an issue with something like a OpType*/OpVariable I could print that information out as well

[Firestar99]

Here's my suggestion:

error 35: OpAccessChain reached non-composite type while indexes still remain to be traversed.
  %26 = OpAccessChain %_ptr_StorageBuffer_v4float %6 %int_0 %int_0 %int_0
 --> ./a.comp:7:33
  |
7 |    data = vec4(0.0);
  |    ^^^^ could also put the error here?

What I like about it:

• the line number of the error is obvious, though does require some padding
• ./a.comp:7:33 is something an IDE can turn into a clickable link
• exposes column information from OpLine
  • use previous OpLine for the :7:33 number
  • mark area with ^ from previous OpLine column to next OpLine
  • I don't know if and how glslc or slang emit columns, which may dictate how well this works in practice. Maybe we could even ask them to emit their OpLines different if that makes this easier?
  • How to handle intermittent OpNoLine? rust-gpu likes to intersperse those sometimes

This is heavily inspired by how errors look in Rust, and then simplified:

Text form

error[E0308]: mismatched types
  --> src/base_plane.rs:24:33
   |
24 |               base_color_channel: Color::Srgba(
   |  _________________________________^
25 | |                 Srgba::new(0.3, 0.5, 0.3, 1.0).mix(&Srgba::WHITE, 0.5),
26 | |             ),
   | |_____________^ expected `UvChannel`, found `Color`

[spencer-lunarg]

@Firestar99 thanks, I updated the PR, now looks like

  --> a.comp:6:0
  |
6 | void main() {
7 |     data = vec4(0.0);
8 | }
  |

My goal is to just get "something" in, then after will focus on improving it adding things like Columns (slang does a good job adding them, glslang is a bit worse)

I imagine this will be an ongoing effort to improve the error logging format as crazy cases come out