undefined | Better HN

0 pointsMindSpunk2mo ago0 comments

WebGPU is far from cheap and has to do a substantial amount of extra work to translate to the underlying API in a safe manner. It's not 1:1 with Vulkan and diverges in a few places. WebGPU uses automatic synchronization and must spend a decent amount of CPU time resolving barriers.

You can't just ship a WebGPU implementation in the driver because the last-mile of getting the <canvas> on screen is handled by the browser in entirely browser specific ways. You'd require very tight coordination between the driver and browsers, and you still wouldn't be saving much because the overhead you get from WebGPU isn't because of API translation, rather it's the cost to make the API safe to expose in a browser.

0 comments

reactordev2mo ago

We already do this by exposing the canvas surface with a semaphore lock. The browser can flip the surface to the canvas (or your app can flip it onto a window surface).

It’s just a HINSTANCE pointer.

You’re right about the waiting, but that’s entirely app driven. Browsers don’t want to render at 144fps but rather wait until drawing has occurred in order to update the view.

wgpu, dawn, already support drawing to arbitrary surfaces (not just a canvas but any window surface).

DiabloD32mo ago

You've mentioned dawn more than once, but isn't dawn dead since the team at Google that was working on it isn't part of either the Android nor Chrome teams, and Android and Chrome both have their own (and incompatible with each other) preferred API manglers?

j / k navigate · click thread line to collapse