"Each error scope stores only the first error it captures; any further errors it captures are silently ignored." is one of the worst design decisions I've ever seen. That means if code is expecting one error to occur, any unexpected errors that occur after it in the scope are unobservable. The only way to handle that would be to push/pop tons of scopes.

How hard is it to make an array of errors instead of a single slot? What's the upside of this other than laziness?

The worst?

No, that belongs to VB:

> On Error Resume Next

Literally, "Ignore the error, and continue as if nothing bad had happened".

That's the worst design decision ever when it comes to error handling.

Only storing the first error is bad, but that's why they describe it as a problem with WebGL that they solve in WebGPU by using a stack.

These kinds of errors are usually programmer errors that cause literally hundreds of downstream errors because they put an object later used by other code in an invalid state. In these cases only the first error is particularly useful, the rest are just noise.

My team is bringing Unreal Engine 5 to WebGPU, to enable next generation browser games and 3D web applications.

As an official backend, or just for a specific game?

I wonder how you will make Nanite work on WebGPU.

Great. Now how do I call this API from WASM without any intervening JavaScript?

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.

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

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.

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.

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

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

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

Part of the security model of WASM is that guest values are opaque to the host and host values are opaque to the guest. You can get a lot of mileage out of (ref extern) right now. Like if you import document.createTextNode you know the extern ref you get back is a text node and you can wrap the extern up as such in your WASM program. I have wrapped a subset of the DOM and Canvas APIs and made several small programs like a classic todo list example and a small retro video game rendered to canvas. I've been able to create elements, assign event handlers, use setTimeout/requestAnimationFrame, etc. all from within WASM. So while additional proposals could add more useful reference types (such as (ref string) from the stringref proposal) you can already do a lot with the types that are there now that reference types + GC are part of core WASM.

You don't.

Maybe when reference types eventually become a thing.

WASM GC reference types are rolling out to stable browser releases now. Chrome 119 just shipped with them enabled by default.

Those ones are unrelated to exposing browser APIs directly to WASM code.

Setup is still required.

I don't quite understand what you mean. WASM modules don't have direct access to anything. They have to be granted capabilities from by the host. Are you referring to optimizations that various engines do where they recognize well-known imports like Math.sin and compile things such that they don't invoke JS at all?

Exactly, hence it is currently impossible to use WebGPU without JavaScript's help.

There are some proposals regarding exposing the browser IDL to WASM via reference types, but it is far from happening.

You need the host (whatever it is) to provide the capabilities to WASM. On the web, the host environment is JS. Browser engines are free to optimize well-known imports with or without any new proposals. I guess I just don't really see the issue...

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.

Soon, even our game engines will be written in JavaScript: https://www.youtube.com/watch?v=_SCfNhyIo_U

Snark aside, the best resource I've found for learning WebGPU is: https://webgpufundamentals.org/

We are building a full game engine and editor fully in JavaScript [1], and we've got WebGPU support too [2].

[1] https://www.construct.net

[2] https://www.construct.net/en/blogs/construct-official-blog-1...

WebGPU will always have the issue to lang behind native capabilities.

It is good enough if aiming to PS3 like games, though.

Any WGPU users among us? How does native and web performance, with the same graphics code, compare?

Whatever WGPU might do in addition to WebGPU is naturally going beyond the standard features a browser is expected to provide, thus no different from any other graphics middleware.

It's heavily sandboxed, and there are other overheads to get around.

And has 2015 state of the art hardware as inspiration, in 10 years time we might finally get mesh shaders and raytracing, looking at how long it took to get OpenGL ES 3.1 compute shaders available.

I thought that video was going to be The Birth & Death of JavaScript

https://www.destroyallsoftware.com/talks/the-birth-and-death...