4 ms·

WebGPU Error Handling best practices

73 points by markdog12 4y ago

throwaway12245 4y ago
What is the release status of WebGPU? Seems like it changes so fast that browser support , i.e. Firefox nightly for example, is spotty.
- modeless 4y ago
  It is going to ship soon in Chrome: https://groups.google.com/a/chromium.org/g/blink-dev/c/VomzPhvJCxI/m/SUhU9Z0vAgAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/VomzP...
  - pjmlp 4y ago
    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.
- dmitriid 4y ago
  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.
- fulafel 4y ago
  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")
kevingadd 4y ago
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.
- modeless 4y ago
  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.
zagrebian 4y ago
Does that blog have an RSS feed?
- FredrikMeyer 4y ago
  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.
  - zagrebian 4y ago
    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.
unconed 4y ago
>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".

73 points by markdog12 4y ago

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

modeless 4y ago
It is going to ship soon in Chrome: https://groups.google.com/a/chromium.org/g/blink-dev/c/VomzPhvJCxI/m/SUhU9Z0vAgAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/VomzP...
- pjmlp 4y ago
  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.
dmitriid 4y ago
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.
fulafel 4y ago
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")

kevingadd 4y ago

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.

modeless 4y ago
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.

zagrebian 4y ago

Does that blog have an RSS feed?

FredrikMeyer 4y ago
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.
- zagrebian 4y ago
  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.

unconed 4y ago

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