You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'll spare the preamble and just get to the point: it'd be really great to be able to use WGSL + wgpu (and the crates that depend on them) in a WASI or similar server-like environment to abstract away differences in GPUs and shader languages. There is no "official" proposed specification for WebGPU in WASI, so this is probably a moonshot until then, and I started work on this only to find out that changes would ripple across nearly all wgpu-* crates, and so put it aside until this discussion could be had.
What would be needed:
(if adopting the WASM Component Model) a WIT definition derived from the webgpu.h header or WebGPU WebIDL
an additional wgpu-hal::Instance which would be enabled in wasm32, non-emscripten environments and (in the guest WASM) would be simply makes calls to the bindings
a host implementation (for wasmtime, wasmer, etc) that mediates between the bindings and either wgpu directly or wgpu-native
Nice to haves:
tree-sitter or similar tool to automatically sync changes in webgpu.h to the WIT definition
an explicit proposal to add WebGPU
Upsides:
projects like burn and downstream crates that build onwgpu would "just work" when compiled to wasm32-wasi executed by a webgpu-enabled runtime
source code for games/visualizations/etc could be compiled to run outside the browser (via winit, or a similar WASM Component stub library)
Downsides:
might introduce a premature maintenance burden, as efforts to standardize WebGPU without JS seem non-existant
Alternatives:
I/someone could just roll out a WASM component that mimics the web_sys::Window and wgpu APIs, though that has its own maintenance burden
also, without nearly-identically copying the informal wgpu crate API, wgpu-dependent crates wouldn't be patch-able
... perhaps there's an easier, less intrusive way? Open to suggestions
Anyways, I hadn't yet seen a singular issue/discussion/etc anywhere regarding wgpu + WASI (aside from bytecodealliance/wit-bindgen#175), and so this might be a bit off-base regarding the actual requirements to implement this, but I thought it worthy to create it here to at least initiate the discussion.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I'll spare the preamble and just get to the point: it'd be really great to be able to use WGSL +
wgpu
(and the crates that depend on them) in a WASI or similar server-like environment to abstract away differences in GPUs and shader languages. There is no "official" proposed specification for WebGPU in WASI, so this is probably a moonshot until then, and I started work on this only to find out that changes would ripple across nearly allwgpu-*
crates, and so put it aside until this discussion could be had.What would be needed:
webgpu.h
header or WebGPU WebIDLwgpu-hal::Instance
which would be enabled inwasm32
, non-emscripten environments and (in the guest WASM) would be simply makes calls to the bindingswgpu
directly orwgpu-native
Nice to haves:
webgpu.h
to the WIT definitionUpsides:
wgpu
would "just work" when compiled towasm32-wasi
executed by a webgpu-enabled runtimewinit
, or a similar WASM Component stub library)Downsides:
Alternatives:
web_sys::Window
andwgpu
APIs, though that has its own maintenance burdenwgpu
crate API,wgpu
-dependent crates wouldn't bepatch
-ableAnyways, I hadn't yet seen a singular issue/discussion/etc anywhere regarding
wgpu
+ WASI (aside from bytecodealliance/wit-bindgen#175), and so this might be a bit off-base regarding the actual requirements to implement this, but I thought it worthy to create it here to at least initiate the discussion.Additional links:
https://github.com/WebAssembly/wasi-webgpu
https://github.com/MendyBerger/wasi-webgpu
Beta Was this translation helpful? Give feedback.
All reactions