WebGPU Implementation

[crowlKats]

I have been looking at the WebGPU spec and the wgpu crate for a possible WebGPU implementation which arose from a discussion on the discord server.
Problem is, how would we handle the window on which the user would draw to? Adding a window manager to deno would definitively not be a viable solution. wgpu-rs does actually allow to have a windowless setup, but i think most end users would actually want a way to have some sort of window. A window is also required for usage of swap chains; which, once again, many users would want.

[ry]

Glad you're looking into this. I was imagining we would start with a windowless setup. The goal is to run tensorflow.js's WebGPU backend.
https://github.com/tensorflow/tfjs/tree/master/tfjs-backend-webgpu

[0kku]

i think most end users would actually want a way to have some sort of window

[citation needed]

I think the more useful use-case would be ML (TF with WebGPU backend), server side image processing, and other GPU compute tasks. I'm not sure how much sense it would make to write a UI in raw wgpu when you're writing JS/TS. Seems like a questionable pairing, and people probably should just host a PWA on the localhost and render in their browser if they want a GUI.

[crowlKats]

@0kku good point, didnt really think about that

[kitsonk]

Ref #5701, #1629

[crowlKats]

gfx-rs/wgpu#869

[crowlKats]

I came up with a solution for adding window support for webgpu without adding any other deps.
This would require plugins to have access to the resourcetable tho.
The community (or we in std) would create plugins for rust window handlers. The surface which you pass to wgpu is created with a param that needs to be a raw_window_handle::HasRawWindowHandle (which is a standarized way to get a raw window handle by the different rust window managers). We would have a deno property on the descriptor for GPU.requestAdapter (like on workers) where you could pass a rid for such a HasRawWindowHandle.

[chances]

@crowlKats Considering the open PR, shall I formally abandon chances/deno-wgpu, i.e. archive the repo and link back here?

[crowlKats]

@chances would make sense

[cztomsik]

Hey, not sure where to ask, is this going to be optional somehow? It seems like quite a big feature, including WSGL parser, compiler, there's some runtime memory overhead as well. I'd expect this to be a native plugin. Webview was also possible with plugin so why not this?

[lucacasonato]

@cztomsik This is a Web API. We implement these out of the box, without the need for external plugins (see fetch, TextEncoder, etc). Deno is modular, so if you want to build a runtime that does not contain WebGPU, that is totally possible. Deno however has shipped this experimental feature feature in 1.8.0. We are hoping to be able to reduce the runtime memory overhead in the coming weeks (the overhead is about 1MB of extra heap). It is and will not be optional in the Deno binary that we ship.

[cztomsik]

Unless something changed recently, WebGPU is still just working name for future standard. There is no initial release yet and support is basic/feature-flagged even in latest browsers:

[lucacasonato]

@cztomsik That is why it is experimental, and locked behind the --unstable flag. We are very aware that it is not stabilized anywhere yet (that is why it is not stabilized in Deno either) - it is a highly unstable API, and the spec is far from complete. It is implemented in Chrome Canary behind a flag, in Firefox Nightly behind a flag, and in Safari TP and Safari stable behind a flag. This API will land sooner or later, and it opens up some amazing possibilities for out of the box general purpose GPU accelerated processing (for example ML inference and learning).

Editor's draft spec: https://gpuweb.github.io/gpuweb/

[birkskyum]

Times are changing, and WebGPU is enabled by default in Chrome. Can this be reopened for a discussion around this in the present context?

[birkskyum]

• feat: bring back WebGPU #20812

[felipetesc]

I came up with a solution for adding window support for webgpu without adding any other deps.

Perhaps this is out of the scope, but what about ressurrecting the project https://github.com/denosaurs/pane, or to create winit bindings. winit works well with wgpu. rust-windowing also has the repo https://github.com/rust-windowing/softbuffer which would allow creating 2D buffer/image, and would help on #3234 .

[eliassjogreen]

I came up with a solution for adding window support for webgpu without adding any other deps.

Perhaps this is out of the scope, but what about ressurrecting the project denosaurs/pane, or to create winit bindings. winit works well with wgpu. rust-windowing also has the repo rust-windowing/softbuffer which would allow creating 2D buffer/image, and would help on #3234 .

Totally! I think it would not require much to bring back pane now that webgpu support is coming back.