Deno 1.39: The Return of WebGPU
deno.com
deno.com
have you tried denog (fork of deno which uses winit for Windowing and also has WebGPU support)? https://github.com/denogdev/denog
As for deno proper, according to this thread, it looks like one of the Deno maintainers has been working on Windowing support, also using winit (same as denog linked above) - https://github.com/gfx-rs/wgpu/pull/3265#issuecomment-140065...
The fork is already ~1700 commits out of date with the original. How often would they sync, etc.?
I just "worry" (in an unsolicited advice fashion might I add) is there a better alternative to maintain this longterm
Offtopic: Does anybody know if the WebAssembly runtime inside deno (which is actually the runtime inside v8) is exposed by any of the deno crates? A cursory search seems to indicate that it isn't. You can access it from `deno_core` through javascript, of course.
and use `deno compile` to ship it as a self contained binary
This would also be an opportunity to build better cross-platform APIs than what's available in browsers (e.g. WebAudio, fullscreen, pointer lock, text input (input in general), networking, ... are all a royal PITA on the web - basically any web API that isn't WebGL or WebGPU is mostly broken or half-assed).
So lets call it a game engine using JavaScript, instead of the usual ones.
It's nothing groundbreaking. It would just be a nice and convenient, is all.
HTML+CSS would be left out entirely.
The browser gives you a lot of valuable functionality.
Rendering an UI that even remotely looks "native" is harder with HTML+CSS than a handful of straightforward rendering primitives which can be implemented on top of WebGPU.
High quality text rendering is a bit non-trivial of course, but that's also only an issue if you want to do a native-looking UI (but mostly irrelevant for games).
Chrome's implementation (C++): https://dawn.googlesource.com/dawn
Firefox's implementation (Rust): https://github.com/gfx-rs/wgpu/
I'm very confused because every comment you have posted in this reply chain makes no sense in the context of the actual blog.
> The WebGPU API gives developers a low level, high performance, cross architecture way to program GPU hardware from JavaScript. It is the effective successor to WebGL on the Web. The spec has been finalized and Chrome has already shipped the API. Support is underway in Firefox and Safari.
Interestingly, the Deno team previously attempted[0] this and rolled it back due to instability. Once this is stable, it means that ML/AI workloads will be accessible to JS developers:
> These days, most neural networks are defined in Python with the computation offloaded to GPUs. We believe JavaScript, instead of Python, could act as an ideal language for expressing mathematical ideas if the proper infrastructure existed. Providing WebGPU support out-of-the-box in Deno is a step in this direction. Our goal is to run Tensorflow.js on Deno, with GPU acceleration. We expect this to be achieved in the coming weeks or months.
[0] https://deno.com/blog/v1.8#experimental-support-for-the-webg...
Outside of "everyone uses js", why do we believe this? What makes JS "ideal".
I would think for machine learning one would want:
- generally default to non-mutating, functional representation of ideas, with convenient escape hatches
- treats the GPU as a concurrent (or better yet, distributed) resource
- can seamlessly run ML code as either immediate or an optimized graph.
- could swap out compute resources as asynchronous rpc, like, flex out to something more powerful if available and needed
Certainly most of these are possible in JS, but I would hardly call it "ideal" for these bullet points, not to mention other general concerns like a highly questionable dependency management ecosystem.
When you use a jupyter notebook the kernel wastes a lot of resources on visualization and the support for interactive visualization isn't ideal (copy all your data to json, pass that to a JS library which has to do the work).
Take a look at ObservableHQ for an idea of what an interface might look like, then imagine numpy semantics and webGPU on top.
As a bonus: run on server or in browser locally would reduce cloud bills because you don't need a whole server to do an exploratory analysis.
Yeah, stupid overloading like C++ IO is a mess, but I haven't encountered much such abuse in Python.
The accessibility and diverse ecosystem of JavaScript, owing to its status as the lingua franca of software development, would probably be the basis for it being "ideal". I think it would be hard to make an objective claim that one programming language is strictly better than another as a programming language for mathematical ideas.
s/software/web/
giving them the benefit of the doubt, perhaps they mean is that it's ideal having these capabilities accessible in JS since it can be run (almost) everywhere and there are a ton of developers who know JS
As someone who detests python, I really hope we can get some good TS WebGPU libs going. In fact any ML lib using WebGPU under the hood would be quite portable to other languages and platforms.
> The [WebGPU] spec has been finalized
but the official WebGPU spec [1] still describes it as a draft. Have I misinterpreted something here or is there some missing context around Deno's statement?
Recent example: I've got a Deno server running a production service. I needed to make some bulk changes in the DB, and I was able to import DB types and utils directly from the main server project and quickly write a TypeScript script that used them to make the changes I needed, with the new script being the entrypoint, no config changes made, and the rest of the project being ignored. This would be practically impossible in a Node.js project that used any TypeScript, ES modules, etc.
Based on current progress in browsers, I'd guess at least 2 will have it enabled without flags by end of Q1 2024. Chrome sort of already does, but for select platforms only.
I highly doubt the API will change from now till then.