W3C Community Group Draft Report – WebGPU Explainer

> 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.

I don't understand what you mean? With the --reference-types flag I mentioned, wasm-bindgen is literally passing the JavaScript objects in and out of the shims with absolutely no serialization or indirection on the JavaScript side: the only indirection is on the module's side, when it stores all the host references in a big table and passes around indices to them.

To give a concrete example, I've attached the entirety of the JavaScript code that wasm-bindgen generates with --reference-types enabled on its WebGL example [0]. You can see how many of the shims do absolutely nothing but call the underlying function, even when they take arbitrary JS objects as arguments:

    imports.wbg.__wbg_attachShader_06c432ad16c8823a = function(arg0, arg1, arg2) {
        arg0.attachShader(arg1, arg2);
    };
    imports.wbg.__wbg_bindBuffer_c0ef32bca575b1bf = function(arg0, arg1, arg2) {
        arg0.bindBuffer(arg1 >>> 0, arg2);
    };
    imports.wbg.__wbg_clear_7f98b4d14a417e94 = function(arg0, arg1) {
        arg0.clear(arg1 >>> 0);
    };
    imports.wbg.__wbg_clearColor_d0e4ba6b3de36fbc = function(arg0, arg1, arg2, arg3, arg4) {
        arg0.clearColor(arg1, arg2, arg3, arg4);
    };
    imports.wbg.__wbg_compileShader_81181e6a219b7098 = function(arg0, arg1) {
        arg0.compileShader(arg1);
    };

So as you can see, we already have direct bridging, as long as the JS objects can be treated as opaque. In fact, the code works just as well if we ditch the anonymous functions entirely, and import the native methods directly into the WASM module (though wasm-bindgen currently doesn't do this on its own, and I have no idea how this affects performance):

    imports.wbg.__wbg_attachShader_06c432ad16c8823a =
        Function.prototype.call.bind(WebGL2RenderingContext.prototype.attachShader),
    imports.wbg.__wbg_bindBuffer_c0ef32bca575b1bf =
        Function.prototype.call.bind(WebGL2RenderingContext.prototype.bindBuffer),
    imports.wbg.__wbg_clear_7f98b4d14a417e94 =
        Function.prototype.call.bind(WebGL2RenderingContext.prototype.clear),
    imports.wbg.__wbg_clearColor_d0e4ba6b3de36fbc =
        Function.prototype.call.bind(WebGL2RenderingContext.prototype.clearColor),
    imports.wbg.__wbg_compileShader_81181e6a219b7098 =
        Function.prototype.call.bind(WebGL2RenderingContext.prototype.compileShader),

Serialization and deserialization are really only needed if we have record types filled with raw data like numbers and strings that we want to ergonomically manipulate on the JavaScript side. If we just need to track opaque handle objects, as with WebGL or WebGPU, then WASM's feature of host references is already sufficient to avoid serialization overhead.

[0] https://gist.github.com/LegionMammal978/9c4ac4de47b3b365a50a...

The issue is that currently this is impossible "Now how do I call this API from WASM without any intervening JavaScript?".

Now the Web IDL bindings have evolved to some kind of reference types, and that is what I was talking about, not GC reference types.

https://www.w3.org/2018/12/games-workshop/slides/08-web-idl-...

https://hacks.mozilla.org/2019/08/webassembly-interface-type...

https://component-model.bytecodealliance.org/introduction.ht...

However I did the mistake to keep calling them reference types, when in reality they are now called component model.

As for the browser, yeah that is what matters for WebGPU, outside of the browser there are so many middleware options with much better tooling (GPU debuggers for Web 3D still aren't a thing 10 years later, besides poor SpectorJS), and access to latest hardware features, instead of what was the state of the art in 2015.