4 ms·

You'll need some JavaScript to instantiate the WASM module and pass in a set of imported functions for using WebGPU. After passing in the capabilities it can be

You'll need some JavaScript to instantiate the WASM module and pass in a set of imported functions for using WebGPU. After passing in the capabilities it can be all WASM from there.

jauntywundrkind 3y ago
Afaik, there's no means to pass in imported functions right now. Rust has a very extensive bindgen to make it kind of look like you can, but it's really a huge payload of js running on the page's main-thread that's converting back and forth. At significant cost. We just shipped garbage collection, which is one precondition to actually being able to pass things around (so things passed in can participate properly in gc). Next is component-model, which allows for passing non-trivial objects around; currently it's just primitives like numbers that can be passed. After that goes in, hopefully it won't be long before we have host-object bridging, where platform objects can be sent across. https://github.com/WebAssembly/component-model https://github.com/WebAssembly/component-model
- davexunit 3y ago
  You can pass around arbitrary JS objects via the (ref extern) type. The (import "module" "name" ...) form can be used to declare an imported thing (function, global, memory, table.) I don't do Rust so I don't know what the limitations are with Rust on WASM right now but speaking just about core WASM stuff all the basic pieces are there now.
  - jauntywundrkind 3y ago
    Afaik, no. What you are talking about is the future, not anything available on any platforms today. Right now, different runtimes don't have any way to communicate what type an object or function is. That's what component model is trying to figure out. Without that, there's not really a way for a ref to do anyone any good, as far as I know. If you can link any docs or examples, that'd be great. I feel like it's been a long long long wait, & I've been very eager. But if I'm mistaken, and passing stuff across boundaries is possible, that'd be amazing to see.
    - LegionMammal978 3y ago
      > Right now, different runtimes don't have any way to communicate what type an object or function is. That's what component model is trying to figure out. Without that, there's not really a way for a ref to do anyone any good, as far as I know. All of that seems like more of a convenience than a necessity: even with just the current implementation of host references, it's perfectly possible to track objects purely through indices into a big table, using reference-counting on the module's side, with no JS assistance necessary. In fact, wasm-bindgen has already implemented support for tracking JS objects as host references in this way, via the --reference-types flag [0]. I've tried out this flag with their WebGL example, and the shims are indeed very minimal: JS objects passed as input aruments go directly into the target functions, without any sort of decoding or lookups. However, JS objects as outputs are still inserted into the table by the shims (calling back into the module to get a free index), which I presume is just a limitation of Rust not being able to express a host reference stored in a local while calling another function. So overall, there's no fundamental issue blocking native functions (or methods, through a bound Function.prototype.call) from being called from WASM with no shims at all, as long as the module can implement any sort of basic index allocator. Though I'd imagine sufficiently-simple shims would get compiled down to hardly anything regardless, in case that turns out to be more performant than Function.prototype.call. [0] https://rustwasm.github.io/wasm-bindgen/reference/reference-types.html https://rustwasm.github.io/wasm-bindgen/reference/reference-...
      - jauntywundrkind 3y ago
        wasm-bindgen is writing it's own ABI, but still involves a ton of auto-generated JS stubs running for you in the background. it works great! you would never know it's there, but it has a serious performance hit versus actual host object bridging (what we're working towards) since it has to keep serializing things over MessageChannels. You can read some about the auto-generated shims here, https://rustwasm.github.io/docs/wasm-bindgen/contributing/design/importing-js.html https://rustwasm.github.io/docs/wasm-bindgen/contributing/de... . And you can see that wasm-bindgen doesn't actually send objects into Rust, but instead has shims here: https://rustwasm.github.io/docs/wasm-bindgen/contributing/design/js-objects-in-rust.html https://rustwasm.github.io/docs/wasm-bindgen/contributing/de... Component Model is designed to eliminate the need for having this autogenerated rpc system & many of these shims, and let wasm itself actually hold references & invoke/use objects in a genuinely shared fashion.

You'll need some JavaScript to instantiate the WASM module and pass in a set of imported functions for using WebGPU. After passing in the capabilities it can be all WASM from there.

jauntywundrkind 3y ago

Afaik, there's no means to pass in imported functions right now. Rust has a very extensive bindgen to make it kind of look like you can, but it's really a huge payload of js running on the page's main-thread that's converting back and forth. At significant cost. We just shipped garbage collection, which is one precondition to actually being able to pass things around (so things passed in can participate properly in gc). Next is component-model, which allows for passing non-trivial objects around; currently it's just primitives like numbers that can be passed. After that goes in, hopefully it won't be long before we have host-object bridging, where platform objects can be sent across. https://github.com/WebAssembly/component-model https://github.com/WebAssembly/component-model

davexunit 3y ago
You can pass around arbitrary JS objects via the (ref extern) type. The (import "module" "name" ...) form can be used to declare an imported thing (function, global, memory, table.) I don't do Rust so I don't know what the limitations are with Rust on WASM right now but speaking just about core WASM stuff all the basic pieces are there now.
- jauntywundrkind 3y ago
  Afaik, no. What you are talking about is the future, not anything available on any platforms today. Right now, different runtimes don't have any way to communicate what type an object or function is. That's what component model is trying to figure out. Without that, there's not really a way for a ref to do anyone any good, as far as I know. If you can link any docs or examples, that'd be great. I feel like it's been a long long long wait, & I've been very eager. But if I'm mistaken, and passing stuff across boundaries is possible, that'd be amazing to see.
  - LegionMammal978 3y ago
    > Right now, different runtimes don't have any way to communicate what type an object or function is. That's what component model is trying to figure out. Without that, there's not really a way for a ref to do anyone any good, as far as I know. All of that seems like more of a convenience than a necessity: even with just the current implementation of host references, it's perfectly possible to track objects purely through indices into a big table, using reference-counting on the module's side, with no JS assistance necessary. In fact, wasm-bindgen has already implemented support for tracking JS objects as host references in this way, via the --reference-types flag [0]. I've tried out this flag with their WebGL example, and the shims are indeed very minimal: JS objects passed as input aruments go directly into the target functions, without any sort of decoding or lookups. However, JS objects as outputs are still inserted into the table by the shims (calling back into the module to get a free index), which I presume is just a limitation of Rust not being able to express a host reference stored in a local while calling another function. So overall, there's no fundamental issue blocking native functions (or methods, through a bound Function.prototype.call) from being called from WASM with no shims at all, as long as the module can implement any sort of basic index allocator. Though I'd imagine sufficiently-simple shims would get compiled down to hardly anything regardless, in case that turns out to be more performant than Function.prototype.call. [0] https://rustwasm.github.io/wasm-bindgen/reference/reference-types.html https://rustwasm.github.io/wasm-bindgen/reference/reference-...
    - jauntywundrkind 3y ago
      wasm-bindgen is writing it's own ABI, but still involves a ton of auto-generated JS stubs running for you in the background. it works great! you would never know it's there, but it has a serious performance hit versus actual host object bridging (what we're working towards) since it has to keep serializing things over MessageChannels. You can read some about the auto-generated shims here, https://rustwasm.github.io/docs/wasm-bindgen/contributing/design/importing-js.html https://rustwasm.github.io/docs/wasm-bindgen/contributing/de... . And you can see that wasm-bindgen doesn't actually send objects into Rust, but instead has shims here: https://rustwasm.github.io/docs/wasm-bindgen/contributing/design/js-objects-in-rust.html https://rustwasm.github.io/docs/wasm-bindgen/contributing/de... Component Model is designed to eliminate the need for having this autogenerated rpc system & many of these shims, and let wasm itself actually hold references & invoke/use objects in a genuinely shared fashion.