support for emscripten build

[caiiiycuk]

Added support for emscripten build. It's draft because, I am waiting for completion of other PRs (wgpu, headers).
Also, how I can edit wiki to add emscripten instructions?

--

[caiiiycuk]

Blocked by:

• Update wgpu to 08ef577  #168
• emscripten: use uint64_t instead of pointers webgpu-native/webgpu-headers#146
• feature = emscripten, compability fixes for wgpu-native wgpu#2450
• +wiki

[caiiiycuk]

@kvark can we fork webgpu-headers under gfx-rs to apply emscripten workaound? webgpu-native/webgpu-headers#146

[kvark]

We can, yeah, although it would be good to not do that:)
Didn't you also try to make our ID to be 32bit on those systems?

[caiiiycuk]

We can, yeah, although it would be good to not do that:) Didn't you also try to make our ID to be 32bit on those systems?

Yes I tried, and this solution also works. But, I really worried that 65536 is too small for index/epoch? Or you think its ok?

--

Another solution that I have in mind is to doing copy of headers and patch them when make:

make lib-native-emscripten

It will cp webgpu.h into emscripten/webgpu.h and patch it. What do you think is it acceptable?

[kvark]

I think 32-bit indices are acceptable, especially with gfx-rs/wgpu#2462 merged.
It's certainly not ideal, but it should work.

[caiiiycuk]

ready

[kvark]

this shouldn't be needed - wgpu-core already depends on wgpu-hal with emscripten feature enabled

[kvark]

I wonder if wgpu-core could detect the need for id32 automatically? Basically, to make it a platform detection instead of an explicit feature.

[rajveermalviya]

Closing this as on web/wasm Emscripten provides it's own webgpu.h implementation which binds to the WebGPU JS functions directly. It doesn't make sense for wgpu-native to "support" emscripten if user wants to target browser webgpu.

Only thing wgpu-native can provide in emscripten/wasm context is an implementation of webgpu.h with WebGL2 backend. If that's what users want, then please open a new issue stating your usecase.