Initial precompiled shaders implementation

[SupaMaggie70Incorporated]

Connections
Works towards #3103
Depends on #7831

Also, as this is the start of a big change, I'd like to ping @cwfitzgerald to at least make sure I haven't gone off in the wrong direction.

Description
This adds a CreateShaderModuleDescriptorPassthrough::Generic enum variant which contains code for multiple types of shader source,allows creating passthrough shaders without writing backend specific code (if on metal pass MSL, etc). This variant also includes an optional reflection thing. For now, I don't know exactly what reflection info is needed, but if possible, we should make sure this can live in wgpu-types or wgpu-core to avoid dependency on naga. It seems the best model for this is the wgpu_core::validation::Interface, we might just have to replace some of the naga types.

Using this requires enabling the EXPERIMENTAL_PRECOMPILED_SHADERS feature. This feature is only supported on DX12, Vulkan, and Metal. Logic on these backends is otherwise identical to the respective specific passthrough methods.

Nothing is currently done with the reflection info.

An overview of my approach can be found in this comment. If this process takes longer than expected we can make a tracking issue. For now I will be posting updates by editing that comment and referencing it in PRs.

Testing
No testing yet. However, the code seems somewhat small and robust.

Squash pls

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy --tests. If applicable, add:
  • --target wasm32-unknown-unknown
• Run cargo xtask test to run tests.
• If this contains user-facing changes, add a CHANGELOG.md entry.

[cwfitzgerald]

Hmm, I think in general I like the ideas put forward in your plan you wrote up, that makes sense to me. As for the code changes themselves, I don't think that we need another variant internally - this feels redundant when all the other variants exist. Maybe what would need to be added is an optional reflection info to each of the variants?

[SupaMaggie70Incorporated]

@cwfitzgerald The purpose of this variant is so that the user can pass a single shader without considering backend-specific code. This way we can also later on add a macro that creates this struct, filling fields for all the backends that are supported, and it doesn't need to be passed a Backend parameter. I can change the approach if you want, but it might make everything a little less clean from the user's point of view.

[cwfitzgerald]

Yeah, I agree that it makes sense in wgpu's api but wgpu-core and wgpu-hal should be able to use the original ones?

[SupaMaggie70Incorporated]

Yeah, I agree that it makes sense in wgpu's api but wgpu-core and wgpu-hal should be able to use the original ones?

True, didn't think about that to be honest. I'll rewrite that part of this PR

[cwfitzgerald]

Sitting down and thinking about this api, I feel there's redundancy here by having both all the individual variants and the combined variant. I think we should have either use the ShaderModuleDescriptorGeneric as-is as the passthrough shader descriptor, or we should ShaderModuleDescriptorGeneric but with individual members replaced with a single enum, which the user of that can then chose. Whatever is generating it can check which backend the device is using.

[SupaMaggie70Incorporated]

@cwfitzgerald I think I prefer the first option here, at least for the user facing option. But I do agree that there is some redundancy here as is. Are you willing to make a decision on which approach to use yet? I'd like to commit to the first and just try to get this pushed through soon (obviously not for 26.0, but I'd like to start working on more aspects on precompiled shaders).

[cwfitzgerald]

@SupaMaggie70Incorporated Alright, lets go with option 1 then! We can always iterate throughout the v26->27 cycle.

[SupaMaggie70Incorporated]

@cwfitzgerald I'm guessing I should keep the existing passthrough features?

[cwfitzgerald]

Hmm. Traditionally we have said you should be able to derive all the information you need from the adapters. However, this isn't true for all the interop or passthrough features. I think that we should just have a single feature for passthrough in general, then you can look at the backend of the adapter.

[SupaMaggie70Incorporated]

@cwfitzgerald Should be good now :) I also added passthrough for WGSL. Its only missing GLSL at this point, so OpenGL doesn't expose the feature. There is no testing for any of this as far as I'm aware, let me know if I should work on that or postpone it to another PR.

[cwfitzgerald]

I added some comments on the code, I want to do some docs adjustments before this lands, but github won't let me do it inline, so I'll push a commit when I have a minute

[cwfitzgerald]

I don't think we can have a single data file anymore, we need to have a single file for each type. Additionally we need to output the hlsl etc. With tracing we need to be able to replicate all the descriptors.

[SupaMaggie70Incorporated]

@cwfitzgerald I wonder if for tracing we should only use the source that is actually used. And yeah good catch, this was just cobbled together so it would still build and have "some" level of tracing

[cwfitzgerald]

I think the intent was that traces should be able to work cross api, but I don't know if that is currently true. The trace infrastructure is broken and pretty neglected.

[SupaMaggie70Incorporated]

I've attempted to address this. Let me know if you think my approach is workable. I haven't done any testing or thought too hard about it, but as you mentioned tracing is in a very sorry state right now.

[SupaMaggie70Incorporated]

I added some comments on the code, I want to do some docs adjustments before this lands, but github won't let me do it inline, so I'll push a commit when I have a minute

All your comments should be addressed :)