Make naga validation errors easier to debug

[LegNeato]

Currently when naga fails validation (when using wgpu +rust-gpu for the web) it can be really confusing and really hard to debug:

• Tips for debugging obscure `naga` validation errors #23
• Get line number where shader validation error occurs #203

We should make it better so it is obvious what naga-generated code is causing the failure and how it maps to the rust-gpu input

[schell]

I don't have the slightest idea how difficult it would be provide source mapping, but that would be amazing. Of course, there's multiple translations here:

• Rust -> SPIR-V
• SPIR-V -> WGSL

And naga doesn't support this currently.

[LegNeato]

With zero knowledge of the details, I can't imagine it would be too hard on the rustc-> spirv side, as rustc likely already has the plumbing because you need to do similar stuff mapping debug symbols back to source code. We'd need to patch naga at least though, yeah.

[LegNeato]

https://doc.rust-lang.org/beta/nightly-rustc/rustc_span/source_map/struct.SourceMap.html

[LegNeato]

On the web side, webgpu supports it: https://developer.mozilla.org/en-US/docs/Web/API/GPUDevice/createShaderModule

But wgpu does not use it (doesn't even generate the API in -sys).

It looks like the Microsoft shader compiler stuff supports embedded pdb and metal supports dwarf debug info.

So much of the plumbing appears to be there.

[wingertge]

I'd like to chime in here and offer help if needed, since I already wrote a debug info implementation for the SPIR-V backend in CubeCL. The extended debug info API (NonSemantic.Shader.DebugInfo.100) can be temperamental but is extremely useful for profiling and debugging shaders, so it would be great to have access to it in rust-gpu. I believe it should be relatively easy to map to the rustc debug symbol plumbing, and it can also be hooked up to dwarf symbols to allow for even more advanced debugging.

I'm not familiar enough with the codebase atm to do my own PR, but if there are any questions I'd be happy to help out. There are some quirks you do need to keep track of (like OpSource directives being ignored unless there's a corresponding OpLine that references it at the start of the function body).