Introspect the shader requirements for validation

[kvark]

We need some way to ask the shader modules for what their expected bindings are, vertex attributes, etc. Currently, it's easy to get the shader mismatched with the pipeline layout, and we aren't validating it.

Edit: here is a tentative plan, and it involves Naga:

• make it so a ShaderModel contains an Option<naga::Module>. The goal is to make it a no-option at some point
• implement the logic of validation at pipeline creation, based on those modules. If the module isn't present, skip the validation.
• when accepting SPIR-V, try parsing it into the module, but don't panic if it fails

Follow-up plan:

• finish render pipeline creation validation
• when accepting WGSL, we have to both parse it, and produce the SPIR-V to feed gfx-rs
• make naga's SPIR-V front-end to work

[fintelia]

I've never used it, but this spirq-rs crate was posted on r/rust_gamedev not long ago, and looks like it might be well suited for doing the necessary shader introspection.

[kvark]

Right, I believe @swiftcoder is looking into it.

[GabrielMajeri]

Is @swiftcoder still working on this, or is it up for contributing?

[kvark]

Doesn't look like @swiftcoder is doing this, consider it available for contribution!

The situation has changed though. We don't want to invest into SPIR-Q, instead we'd want to integrate naga and dog-food it.

The first stage is having naga as an optional dependency, and using its SPIR-V front-end to load the naga::Module (which is our IR). It will not be used to produce anything, but instead - to analyze shader requirements and validate them against the pipeline. We'd allow the SPIR-V front-end to fail, in which case we'd issue a warning and continue without validation (while things settle down).

[GabrielMajeri]

Now that we no longer have wgpu-native and its examples in this repository, how could I go around testing the shader validation works?

Would adding a test that directly calls wgpu-core functions to create a device and loads a .spv from disk work?

[kvark]

The tests you are considering is more than just a shader, it's the whole pipeline. We could just defer this to the point where we could run wgpu-native against WebGPU CTS, which covers the validation purposes.

Alternatively, once #289 is implemented, we'll be able to have small internal tests based on the deserialization of the work.

[GabrielMajeri]

I've looked into this, but I don't know exactly where the introspection & validation would take place.

We are given the raw SPIR-V code in device_create_shader_module. However, the validation would take place when creating computer/render pipelines, at which point we no longer have acces to the original code.

Should we store the SPIR-V code somewhere? Or do we expose this validation functionality as helper functions?

[kvark]

The natural spot for validation is create_render_pipeline and create_compute_pipeline.
What happens on create_shader_module is just parsing the shader and ensuring it's self-consistent to start with (i.e. a valid SPIR-V/WGSL).

Edit: yes, feel free to add more metadata on our struct ShaderModule, such as SPIR-V or some processed version of it.

[kvark]

I've put our plan up in the body of the issue.

The last bit here is not required, but I think it makes sense, because it's fairly easy to build on top of the other steps, and our WGSL front-end is pretty mature, unlike the SPIR-V front-end. The only blocker here is that SPIR-V backend is still not merged - gfx-rs/naga#46 (cc @Napokue ).

So for now, we can't do (4), but we can do the other 3 points in preparation to it. But most importantly, we can start having that validation code based on naga::Module.

[Yamakaky]

Is validating if a buffer has the right BufferStage setting a part of this issue or should I create a new one?

[kvark]

@Yamakaky buffer having the right usage flags is unrelated to this issue. It's about shader requirements only.