Clean up SDL_GpuShaderFormat

[mcclure]

I am very interested in the upcoming SDL-GPU but unfortunately I have not had time to review and test it. However a friend of mine showed me its approach to shader languages, the SDL_GpuShaderFormat enum:

https://github.com/thatcosmonaut/SDL/blob/gpu/include/SDL3/SDL_gpu.h#L193

I have not yet figured out where the documentation for this enum is (not totally clear if there's a specific place SDL-GPU documentation lives yet separate from the headers… a question is asked in https://github.com/libsdl-org/SDL/pull/9312 about this enum but it is not answered) but, I would like to request an entry for WGSL.

As you may know, WGSL is the shader language for WebGPU; although it is frankly infuriating that a decision was made to make WGSL mandatory for WebGPU web targets, once you get past that WGSL is actually pretty nice. It is nice enough that I would, at present, use WGSL when writing WebGPU even if I were targeting solely desktop targets, which support SPIR-V. Since I don't know HLSL and I wouldn't want to go back to GLSL after trying WGSL, if I were to try and choose to adopt SDL-GPU I'd probably initially prefer to use WGSL. I could get this by selecting SDL_GPU_SHADERFORMAT_SPIRV and compiling from WGSL, but a WGSL primitive might help with a future SDL-GPU port for wasm because it could allow wgsl to just be passed through on that platform.

Complications:

• WGSL is a little bit fit to the webgpu platform and I don't know if it would require massaging to fit SDL-GPU's idiom. On the other hand WGSL is also still in the phase it's relatively easy for an outside party to request changes to allow for their own extension points.
• I don't know if it makes sense to add WGSL to the enum before SDL-GPU for wasm+webgpu is even planned
• SDL3-GPU's pipeline seems to rely on tools like spirv-cross, WGSL might complicate that because although WGSL->SPIRV is easy currently, I'm not clear on the status of SPIRV->WGSL and it at least isn't currently a supported feature of spirv-cross specifically
• A separate thought: rather than reserving a space in the enum for WGSL now, it might make sense to— while you still have the chance— rearrange the enum so that SDL_GPU_SHADERFORMAT_SECRET is item # 1, after INVALID, so that future extension at the end of the enum (for WGSL or something else) doesn't look weird with the _SECRET value kinda just in the middle. (Another option would be to set SDL_GPU_SHADERFORMAT_SECRET = 0x1000 or something and have undocumented values with bit 0x1000 high corresponding to individual secret formats, but that might interfere with e.g. using the enum as an array index so idk.)

[flibitijibibo]

We ended up deciding to split the SPIRV-Cross dependency, so it'll be native-to-native only without any built in cross compilers:

https://github.com/thatcosmonaut/SDL/issues/106

So for built-in stuff I wouldn't worry about trying to upstream any translators, it can be a single-file header like it will be for SPIR-V.

I do think we could put SECRET into slot 0 though, and WGSL can be added later if anyone ever makes a webgpu backend.

[thatcosmonaut]

Worth noting that wgpu already has a WGSL -> SPIR-V compiler: https://github.com/gfx-rs/wgpu/tree/trunk/naga

With that tool you should be able to use WGSL if you prefer.

The only reason we accept MSL / HLSL directly is because they are able to be accepted by the backends which use them. If we ever got a webgpu backend then I think adding WGSL would be appropriate, but for now it would force a hard dependency on the webgpu toolchain which is no good.

[thatcosmonaut]

I actually noticed that naga has support for emitting HLSL and MSL now, so if your project's source language is WGSL you can emit shader code for all of our current backends without even needing a SPIRV-Cross dependency.

[mcclure]

Naga is what I use to compile wgsl in my Rust projects (it's the default) and in my experience it works well.

@kg pointed out to me it also currently advertises it can do ("primary support" level) Spir-V as input and ("secondary support" level, whatever that means) WGSL as output. So it is of utility both for WGSL as an input language when targeting non-WebGPU-on-web platforms, and for WGSL as a platform target (assuming either that your input is GLSL or wgsl, or you've already added a step to compile it to spir-v).

[flibitijibibo]

The enum cleanup is now in gpu_next, and it should be set up properly to support a WGSL value in the future if needed.