SPIRV and WGSL support detection

[fridenmf]

Two questions regarding checking support for SPIRV and WGSL:

1. How can I check that using a WGPUShaderSourceSPIRV in WGPUShaderModuleDescriptor is supported? Or can I expect all implementations to implement this? I see no feature flags for this in webgpu.h and wgpu-native panics when trying to use it. Dawn works, but it seems like adding a feature flag for this would make it more safer to use.
2. I'm assuming that WGPUShaderSourceWGSL is always is supported by implementations when running in a browser, is this also true when running natively on desktop with something like Dawn or wgpu-native?

---

EDIT: Todo list

• > I did NOT rename WGPUFeatureName, WGPUSupportedFeatures, and WGPULimits because they're used for both Adapter and Device, so picking one could be confusing. That can be a separate step anyway.

[kainino0x]

1. Totally missed this, you're right, there needs to be a way to detect SPIR-V support. This is probably an instance-level capability... need to think about it.
2. WGSL support is required in all webgpu.h implementations. I can imagine some implementations might have build-time support for omitting their WGSL frontend, but that can be "non-standard".

[kainino0x]

Apr 24 meeting:

• KN: Add a new bool to WGPUInstanceCapabilities? Add an extension struct? Switch it to a features+limits pattern?
• CF: Think it should be instance-level, should use features+limits.
  • Fundamentally instance-level thing, whether your impl knows how to parse SPIR-V.
  • Passthrough shaders are a different thing
  • aside: CF: Don't like that limits work the way they do (you can't request lower than default)
• LK: Add WGPUInstanceFeatureName? WGPUFeatureName→WGPUDeviceFeatureName?
  • WGPUInstanceLimits? WGPULimits→WGPUDeviceLimits?
• CF: Think we should rename these things and leave behind aliases.
  • KN: For enums, have to alias every single thing in the enum, not just the enum.
• …
• KN: Prefer to not break, or to break minimally
• …
• CF: Position comes from the fact that this is going to last a long time. Right now have two different ways to do the same thing. Consistency makes things easier for people.
• KN: I can try to ask for feedback and see if people think it will be too painful
  • Open PR which switches to features+limits, renames the device ones, and adds aliases for them

[kainino0x]

Fixed, feature name thing tracked in #539