All of the browser vendors are supportive, all had initial prototypes etc.
Speculation: The spec is still a Working Draft aka: comments welcome from anyone, may drastically change. Chrome already intends to ship soon. It's quite possible that Chrome is rushing ahead as usual even though the spec hasn't been fully finalized.
There's no ETA for when 1.0 of the spec is coming out that I've seen. Some browsers on some platforms are shipping code behind config options or origin trials. Might be a good guess that it will ship (enabled for end users) this year on first platforms, but hard to say how many years it will take to be broadly useable if you want to support all the big-3 browsers. WebGL 2 just recently made it there...
(And in FF nightly, it's more like "not enabled, no ETA" than "spotty")
The decision to have named error handling scopes on a stack with an asynchronous API feels truly bizarre to me. Now if I write async code that wants to interact with error scopes, I need some sort of complex helper library that manages pushing and popping scopes off the stack and forwarding the results to me, because I don't have any way to pop the specific scope I pushed directly.
The WebGPU API is "asynchronous" in the sense that it schedules work to happen later on the GPU (like all GPU APIs), but the function calls are mostly not `async` at the JavaScript level in the sense that they don't return Promises and you don't `await` them. Error scopes will work for rendering code, which should not be waiting on Promises.
The Feedbro browser extension has a “Find feeds in current tab” feature. If the web page declares a feed in its source code, Feedbro will probably find it. When Feedbro doesn’t find anything, I ask here.
>This all happens in a different thread or even different process than the one that’s running your JavaScript. That’s great for performance,
Is it tho? What is the overhead of passing data across the boundary? What is the limit of the number of draw calls you can make, and how does it compare to a native vulkan or metal rendering loop?
I think what OP meant to write is: "this is necessary to avoid blocking the main UI thread because JS is single threaded, while process isolation is needed because GPU APIs are insecure and buggy".
11 comments
[ 2.4 ms ] story [ 35.2 ms ] threadThey still have WGSL semantics to sort out, and there are a couple of issues postponed for post MVP 1.0.
At least now Chrome Canary for Android has WebGPU support as well, no need to mess with Vulkan directly.
Speculation: The spec is still a Working Draft aka: comments welcome from anyone, may drastically change. Chrome already intends to ship soon. It's quite possible that Chrome is rushing ahead as usual even though the spec hasn't been fully finalized.
(And in FF nightly, it's more like "not enabled, no ETA" than "spotty")
Is it tho? What is the overhead of passing data across the boundary? What is the limit of the number of draw calls you can make, and how does it compare to a native vulkan or metal rendering loop?
I think what OP meant to write is: "this is necessary to avoid blocking the main UI thread because JS is single threaded, while process isolation is needed because GPU APIs are insecure and buggy".