I'm curious if there are technical benefits to interfacing with WebGPU via JS or via WASM (Rust, specifically)?
In general WASM vs (well-written) JS shouldn't matter much for most scenarios, but there's one important drawback when using WebGPU via WASM: any buffer mapping operation needs to do an extra copy to get the data in and out of the WASM heap (e.g. there's currently no way to directly access (another) JS ArrayBuffer object from WASM). It's not a show stopper of course, but something to keep in mind when shuffling a lot of data between the CPU side and WebGPU.
PS: IMHO the biggest downside of using WebGPU natively is that it comes with a builtin shader compiler and/or cross-compiler to translate either WGSL or SPIRV to the shader dialects used by the various backend APIs. This adds a couple of complex dependencies and quite a bit of binary size (much more than "just" the WebGPU implementation). It would be nice if the native WebGPU implementations would allow to move all that shader compile/transpile stuff offline, and feed the WebGPU API with backend-specific shader blobs.
Yep, but at least for the D3D12 and Metal backend the input SPIRV needs to be translated to HLSL (or maybe directly to DXIL?) and MSL. Not sure if the Vulkan backends accept the input SPIRV directly or whether there's also some translation happening.
wgpu supports both a SPIR-V passthrough mode [0] and a regular SPIR-V mode where it will get some transformations added to it (e.g. bounds checks are added on backends without VK_KHR_robustness). I don't believe Dawn has a similar passthrough mode, only a SPIR-V -> transform -> SPIR-V path.
Comments
In general WASM vs (well-written) JS shouldn't matter much for most scenarios, but there's one important drawback when using WebGPU via WASM: any buffer mapping operation needs to do an extra copy to get the data in and out of the WASM heap (e.g. there's currently no way to directly access (another) JS ArrayBuffer object from WASM). It's not a show stopper of course, but something to keep in mind when shuffling a lot of data between the CPU side and WebGPU.
PS: IMHO the biggest downside of using WebGPU natively is that it comes with a builtin shader compiler and/or cross-compiler to translate either WGSL or SPIRV to the shader dialects used by the various backend APIs. This adds a couple of complex dependencies and quite a bit of binary size (much more than "just" the WebGPU implementation). It would be nice if the native WebGPU implementations would allow to move all that shader compile/transpile stuff offline, and feed the WebGPU API with backend-specific shader blobs.
I believe both Dawn and wgpu are planning on supporting SPIR-V ingestion for native use cases,
Yep, but at least for the D3D12 and Metal backend the input SPIRV needs to be translated to HLSL (or maybe directly to DXIL?) and MSL. Not sure if the Vulkan backends accept the input SPIRV directly or whether there's also some translation happening.
wgpu supports both a SPIR-V passthrough mode [0] and a regular SPIR-V mode where it will get some transformations added to it (e.g. bounds checks are added on backends without VK_KHR_robustness). I don't believe Dawn has a similar passthrough mode, only a SPIR-V -> transform -> SPIR-V path.
[0] https://docs.rs/wgpu/latest/wgpu/struct.Features.html#associ...