WebGPU Error Handling best practices | Hacker News Reader

WebGPU Error Handling best practices

toji.dev

73 pointsmarkdog1211 comments

What is the release status of WebGPU? Seems like it changes so fast that browser support , i.e. Firefox nightly for example, is spotty.

It is going to ship soon in Chrome: https://groups.google.com/a/chromium.org/g/blink-dev/c/VomzP...

Lets see if it is really soon, as it was going to be Summer time 2022 really soon as well.

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

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")

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

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.

Does that blog have an RSS feed?

I often check this by opening developer tools, look in the code, and and search for "rss", "atom.xml" or similar things within the <head> tags.

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.

Reply on news.ycombinator.com