WebGPU bindings

[Beyley]

Summary of the PR

Adds WebGPU bindings, generated from webgpu-headers

Related issues, Discord discussions, or proposals

Closes #1113

[Perksey]

Nice! However I think when we discussed this last we decided that work should be done in both BuildTools and SilkTouch to use WebIDL and allow our WebGPU (and eventually WebGL) bindings to work in both Blazor mode (i.e. using Blazor's interop APIs) and native mode (using classical SilkTouch).

We came to the conclusion that it wasn't this simple because the "web" in WebGPU becomes a misnomer if we don't have an explicit code path for it.

[Beyley]

Nice! However I think when we discussed this last we decided that work should be done in both BuildTools and SilkTouch to use WebIDL and allow our WebGPU (and eventually WebGL) bindings to work in both Blazor mode (i.e. using Blazor's interop APIs) and native mode (using classical SilkTouch).

We came to the conclusion that it wasn't this simple because the "web" in WebGPU becomes a misnomer if we don't have an explicit code path for it.

I was thinking more emscripten than blazor webidl, since emscripten has code to convert these C imports, i just need to specify a dllimport with the right name

[Perksey]

I have been against relying on emscripten magic, but looking at other .NET projects this seems to frustratingly be the standard route so that sounds fine with me.

You'll need to use SilkTouch's P/Invoke override functionality as well as add support for Blazor (OperatingSystem.IsBrowser) in the SearchPathContainer logic.

[Beyley]

I have been against relying on emscripten magic, but looking at other .NET projects this seems to frustratingly be the standard route so that sounds fine with me.

You'll need to use SilkTouch's P/Invoke override functionality as well as add support for Blazor (OperatingSystem.IsBrowser) in the SearchPathContainer logic.

Yup the P/Invoke and SearchPathContainer will come in another PR later on, i already have a lot of that done, for the initial merge ittl be a 'wgpu-native' thing only, then i'll make all the bindings i can web-compatible in the main WASM PR
and yeah while relying on emscripten fairy dust isn't the best, it let's users keep a lot of their code identical, and not have to directly write for WebGL/WebGPU(but the slightly different web api)

[Beyley]

If CI passes then i think this PR is ready for a first round of review, i went through and made sure all the struct/function names make sense

[Beyley]

Since initial round of review, some generation problems have cropped up relating to enums being misinterpreted as ints in some structs, namely problems like WriteMask in ColorTargetState, which is incorrectly generated as a uint, rather than a ColorWriteMask, id like to get these fixed before this is taken for another review

[Beyley]

Should be ready for another review (but id like to pause on actually merging until the bindings regeneration is in)

[Beyley]

Found problem with BufferMapAsync, its MapMode isnt being registered as an enum, rather a uint, so dont merge until thats fixed

[Beyley]

Found problem with BufferMapAsync, its MapMode isnt being registered as an enum, rather a uint, so dont merge until thats fixed

This has now been fixed!

[unicomp21]

Is webgl still on the roadmap?

[Beyley]

Is webgl still on the roadmap?

#740