WebGPU support

[Nielsbishere]

Hi,
Are there any plans of supporting GPUWeb at some point in Emscripten? It is currently not really standardized yet, but there are some runtimes available for javascript. I'd think this would map best with Vulkan instead of OpenGL; though both APIs would roughly be able to match from what I've seen.

[kripken]

cc @kainino0x who can give the best answer here.

[kainino0x]

We're in the middle of working on this. (VERY work-in-progress!)
https://github.com/kainino0x/webgpu-cross-platform-demo
(which has a submodule that points at a fork of Emscripten).

We're in the process of developing a common header between Dawn (Chrome's implementation) and wgpu-native (C interface for Firefox's implementation). Once that's done we'll update the Emscripten code to match and eventually make it possible to swap out Dawn, wgpu-native, and WebGPU-through-Emscripten.

In the fork, most of the code is in library_webgpu.js, which could be used without forking Emscripten, except we have a number of changes elsewhere that still require the fork. Now that I'm thinking about it, I should see if it's possible to upstream some of those before upstreaming the final library_webgpu.js so it'll be easier to try out.

[Nielsbishere]

Does that mean that fork works with chrome canary automatically? Or is there a special setup I need to do?

[kainino0x]

See http://webgpu.io for info on trying out WebGPU. This will only work correctly on Chrome for now, but of course it will work on other browsers in the future.

[Nielsbishere]

Yeah I checked some of it out, it seems really promising and I hope it gets adapted widely pretty soon. This means I don't have to support WebGL2, since Vulkan runs almost anywhere natively and this is almost like Vulkan but less verbose. The alternative is WebGL2 + Compute, but that won't work on apple (surprise).

[thewtex]

Are there any plans for Emscripten / WebGPU support for C++ SYCL / Compute?

[kainino0x]

We don't have any plans to work on it, but contributions would be welcome. Some OpenCL should be theoretically possible to implement on WebGPU using clspv. (You could start by prototyping this on a native WebGPU implementation like Dawn.) SYCL could be potentially quite complicated to integrate with Emscripten though.

[kainino0x]

Closing this since we landed WebGPU support in #10218. We'll continue maintaining it as changes are needed.

[jon-chuang]

@kainino0x

SYCL could be potentially quite complicated to integrate with Emscripten though.

Actually, why is this the case? SYCL can generate SPIR-V bytecode can't it?

From what I understand, the compute shader intended to be supported by WebGPU is either SPIR-V or some human readable SPIR-V fork that is convertible to and from SPIR-V. Can't one just target OpenCL/Vulkan directly with SPIR-V? Pardon my ignorance.

[kainino0x]

Sorry, I'm not very informed (have only used CUDA). I did a little more research. I think it may be easier than I thought. In particular, I thought that since SYCL is a single-source language, the Emscripten compiler would need some special understanding to know to ignore GPU code. However it seems like SYCL stays within the standard in such a way that Emscripten does not need to understand.

You would have to somehow teach the SYCL headers how to dispatch work through WebGPU. I'm sure that's doable.

The other concern is that we can only accept code that uses the programming model of Vulkan-flavor SPIR-V (logical addressing mode, etc.) OpenCL SPIR-V will not work. That said, I believe SYCL already supports running GPU code through Vulkan so it should be possible. (We might need some additional extensions in WebGPU though.)

[jon-chuang]

@kainino0x Yes, one would need to write a runtime layer hooking into the underlying WebGPU runtime (I assume for chrome/safari this is dawnnative/wgpu-native). However, this abstraction layer could be implemented in C++, and either run natively, or compiled through emscripten as part of the WASM bytecode, with appropriate SPIR-V codegen.

As you mentioned, existing compilation paths for SYCL are for OpenCL runtime and OpenCL SPIR-V. So naively, a path exists which is to swap to a WebGPU runtime and use clspv to port the device code to Vulkan SPIR-V. Probably what I would have to do is to do a bit more integration than that.

For now, it is unclear to me what exactly the SYCL and WebGPU runtimes do in terms of managing buffers and transfers and handling page faults etc. I should study the underlying model. However, does this mean I need to study Metal and Vulkan runtimes? It seems I can just study dawnnative, especially this header https://github.com/gfx-rs/wgpu/blob/master/ffi/wgpu.h.

I may start playing around with this to better understand the WebGPU runtimes as well as emscripten. Probably, I should be at 90% success if I can compile and run a SYCL source natively through WebGPU, and the rest is to get emscripten to work correctly. Do you have any advice on how I should proceed?

[kainino0x]

wgpu has a package called wgpu-native that exposes a C FFI interface implemented in Rust. Dawn exposes a C interface implemented in C++. Emscripten also exposes a C interface, implemented in JavaScript, that calls into the browser's implementation (which is implemented on top of wgpu or dawn).

Since you want to implement on top of WebGPU, you'll need to use the interfaces provided by WebGPU (for buffers, transfers, etc). WebGPU is not done yet and is not very well documented, but you can start at webgpu.dev for the spec/api and webgpu.io for examples, and experiment with the implementations.

[mateli]

The wgpu (including wgpu-native) supports using both WebGL2 and WebGPU as a backend so it would be useful to be able to fall back on that in case that the browser do not support WebGPU.

[kainino0x]

A WebGL 2 backend would be out of scope for Emscripten (and for Dawn's fork emdawnwebgpu). Our goal is to provide a compliant implementation but it's not possible to do that on top of WebGL 2 (if it were, the browser would just do it).

If you want non-compliant support for a WebGL 2 backend then you should use wgpu-native. (I wasn't actually aware that wgpu-native could be used in Wasm - that's interesting to know about!)

BTW, the upcoming WebGPU Compatibility Mode (https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md), which targets GLES 3.1 as a backend, is in scope for these bindings.

Also please note that we're most likely going to remove the bindings from emscripten itself and direct people toward external libraries - follow #23432 for updates on that.