Enable WebGPU backend for Emscripten builds

[j8asic]

Added support for compiling slang-rhi using Emscripten (WASM), while enabling the WebGPU backend and handling dependencies for the web platform:

• Added logic to detect emscripten
• enable SLANG_RHI_HAS_WGPU and disable incompatible native APIs when building for Emscripten
• Skipped fetching the native Dawn binary package when building for Emscripten
• target_compile_options use modern --use-port=emdawnwebgpu for Emscripten builds
• core rhi code switches between dawn/emscripten functionality

[CLAassistant]

All committers have signed the CLA.

[skallweitNV]

Thanks for the submission. Overall this looks like it's going into the right direction.

FYI, the WebGPU backend in slang-rhi is very much a work-in-progress and very low priority for us at this point in time. We don't expect anything apart from the most trivial examples to run.

If we want to add support for WASM to slang-rhi, we need to add proper testing through CI. My main fear is that we get incompatible versions of Dawn and emdawnwebgpu. Do you know how emdawnwebgpu is versioned? Is it just implicitly versioned through the emscripten version?

[j8asic]

FYI, the WebGPU backend in slang-rhi is very much a work-in-progress and very low priority for us at this point in time. We don't expect anything apart from the most trivial examples to run.

understandable, that's why i'd love to help

If we want to add support for WASM to slang-rhi, we need to add proper testing through CI. My main fear is that we get incompatible versions of Dawn and emdawnwebgpu. Do you know how emdawnwebgpu is versioned? Is it just implicitly versioned through the emscripten version?

This is a pain. Current slang dawn version is old (april 2025?), and seems that emscripten changed versioning from that point. In any case, for now I just decided emscripten is using "newer" webgpu api. There are few cases that have preprocessor checks dawn/emscripten to decide the api call. I see few options to enhance it: use template magic to auto-deduce right api call, or dig a bit on connecting versioning emscripten to dawn (but this would make sense only when Slang updates a bit its dawn version?). Going to think about CI tests now as well...

[skallweitNV]

Taken another look. I think it's fine to merge initial WASM support with a little bit of additional cleanup.

[skallweitNV]

I don't really like this separation because I currently use the tools/extract-webgpu-procs.py script to generate the SLANG_RHI_WGPU_PROCS(x) definition whenever we update Dawn. This will make this tedious.

Maybe just define all of SLANG_RHI_WGPU_PROCS for both the WASM and Dawn case.

[j8asic]

This is the main issue for maintenance. I iterated two-three different solutions and found a compromise as you say to "define all of SLANG_RHI_WGPU_PROCS": since you already have a workflow, I extended your script to fetch (according commit of the) EM webgpu.h, and use it to typedef missing stubs.

[skallweitNV]

Why can't we extract two sets of stubs, one from the currently used Dawn library, the other from the webgpu headers? Maybe that's the wrong approach, but I'm not sure what mixing the two buys us?!

[skallweitNV]

Why can't we extract two sets of stubs, one from the currently used Dawn library, the other from the webgpu headers? Maybe that's the wrong approach, but I'm not sure what mixing the two buys us?!

[skallweitNV]

@j8asic sorry for not responding earlier. Thanks for addressing the review notes.

I think the remaining open question is regarding the WebGPU API entrypoints. I'd prefer defining the stubs twice, one set for Emscripten, the other for Dawn. The script can then just simply iterate over the two headers and emit a set of stubs for each header. This will make diffs cleaner and generally avoid confusion between the two sets of entry points. Maybe I'm missing something obvious here, but this just seems the simpler more straight forward approach to me than extracting a common set.

Did your change to ship WASM binaries for slang releases already land? If so, it would be neat to clean this up as well. Let me know if we need a new Slang release after your changes have landed.

[j8asic]

I think the remaining open question is regarding the WebGPU API entrypoints. I'd prefer defining the stubs twice, one set for Emscripten, the other for Dawn. The script can then just simply iterate over the two headers and emit a set of stubs for each header. This will make diffs cleaner and generally avoid confusion between the two sets of entry points. Maybe I'm missing something obvious here, but this just seems the simpler more straight forward approach to me than extracting a common set.

I thought about this option as well, but went with the current implementation, because Dawn impl assures it implements webgpu.h of emdawngpu + its own extensions; see 1 2. This is also connected to your initial worry on how to define syncing of API versions of dawn and emdawn. I had to manually check em releases compared to current chosen Dawn version. Let me know on your final decision and I will implement any.

Did your change to ship WASM binaries for slang releases already land? If so, it would be neat to clean this up as well. Let me know if we need a new Slang release after your changes have landed.

This got merged after 2026.01, so I similarly suggest we wait for new release containing wasm-libs and clean this up.