feat(spv): shader debug option

[wicast]

Checklist

• Run cargo clippy.
• Run cargo clippy --target wasm32-unknown-unknown if applicable.
• Add change to CHANGELOG.md. See simple instructions inside file.

Connections
#3896

Description
Generate shader debug info for spv

Testing
There are some spv level tests in naga already. Testing with frame debugger is hard to make an autotest.

So the following step needs done by hands:
add debug flag to the shader macro wgpu::include_wgsl!("shader.wgsl", true)); or use struct

wgpu::ShaderModuleDescriptor {
        label: Some("shader.wgsl"),
        source: wgpu::ShaderSource::Wgsl(Cow::Borrowed(include_str!("shader.wgsl"))),
        debug: true,
    }

Make sure wgpu is using Vulkan backend.
Launch compiled exe from Renderdoc and capture a frame and trigger the shader debugger via vertex or pixel.
press F10 to step over and F10+shift to step back.

Test on Win10 19045.3324, Nvidia.

I also tried other debugger like PIX, Nsight, but only Renderdoc support vulkan+spv debug.

I'll test Linux+Renderdoc later.

[Wumpf]

Given that this flag only applies to spirv-out I'm wondering we could find another way to specify this instead of putting it on every ShaderModuleDescriptor

That said, maybe this is something we could expose for more inputs - @teoxoy can you comment on that? If we can make more use of that it's surely a useful pattern, otherwise I'm a bit on the fence, but still pondering what might be better there. We should definitely expose this somehow

[wicast]

Given that this flag only applies to spirv-out I'm wondering we could find another way to specify this instead of putting it on every ShaderModuleDescriptor

That said, maybe this is something we could expose for more inputs - @teoxoy can you comment on that? If we can make more use of that it's surely a useful pattern, otherwise I'm a bit on the fence, but still pondering what might be better there. We should definitely expose this somehow

Honestly I have the same thought on it while writing, but I didn't want to changing the create_shader_module api too much at the time.

Now I have two idea:

1. add another option struct for create_shader_module.
2. add another api on device like set_shader_compile_option, every call on create_shader_module will query this option.

i vote for the second plan, because this will leave create_shader_module unchanged and you don't need to set a debug flag on every shader creation.

[cwfitzgerald]

This kind of switch shows up in multiple places and is likely okay being a instance level switch for all shaders from the instance.

We have a couple things that we want to be able to adjust on the instance level, including turning on/off underlying-api validation, debug labels, and graphics debugger integrations. I'm going to make a instance flags in a PR shortly and this can use that.

[cwfitzgerald]

Ping from triage

[teoxoy]

Sorry for taking a while to respond on this but I think what @cwfitzgerald has in mind sounds good to me.

[cwfitzgerald]

To clarify, I will implement the flags in general very soon, then you can merge on top of that work

[jimblandy]

Firefox wants this. We want to be able to enable the backend's debugging layers in non-debug Firefox builds, for fuzzing and things like that.

[cwfitzgerald]

#2316 is the main issue for the flags

[cwfitzgerald]

#4230 has now landed, giving you a flag to latch onto!

[wicast]

#4230 has now landed, giving you a flag to latch onto!

sure! I will take some time to integrate

[nical]

#4246 adds the plumbing to access the instance flags from the instance or the device.