Now all that's left to do is to integrate a minimal native system glue library into Deno (create a window with a WebGPU canvas, receive input events, audio buffer streaming) and it would be a nice little platform to build and distribute small games and graphics demos written in WebAssembly and/or Typescript :)
I think the ecosystem is inching in this direction. There are already some interesting PoCs out there using Tauri (Rust based) and the deno_core Rust crate.
> 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.
> We believe JavaScript, instead of Python, could act as an ideal language for expressing mathematical ideas if the proper infrastructure existed
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.
Just yesterday I was looking to play around with webGPU and found the 1.8 release page. I had no idea it was removed. I hope that webGPU will gain adaptation as the best cross platform system. The incompatibility between platforms for openGL or Vulkan always made me not want to learn it.
Small correction: It wasn't rolled back due to instability, it was because it increased deno startup time even for programs that weren't making use of WebGPU apis. That is no longer the case this time around.
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.
JavaScript is useless for data exploration, that's why very little data scientist uses JavaScript and all kinds of none white spaces languages.
Curly braces doesn't work well in iterative explorative programming
I've been wondering for a long time when we might expect to see a stable WebGPU API in all major browsers (mostly concerned with my daily browser, Firefox), so I've been looking for an official message on the topic. Deno claims the spec is ready
> 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?
In the W3C process, in order for a TR to upgrade from a Draft to a finished specification, it needs two shipping implementations. Firefox and Safari are both working on theirs. We hope the only changes involved in this process will be minor and/or editorial. Once a second implementation ships, it will move out of draft.
I'm still so bullish on Deno. They iterate quickly, but they also have a clear vision and direction. I've almost completely stopped using Node on personal projects; Deno is the new world I want for non-browser JavaScript.
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.
I gotta admit at the outset I was more than a little sceptical of WebGPU for ML in general but now I have much greater respect for the usefulness of local inference as part of a webapp and the increasing ability to actually run a quantized models in the browser. Glad I was wrong !
That's a formality. Once major browsers ship WebGPU without flags, the spec itself can actually be codified as a standard rather than draft. And I'm sure Deno will follow suit in the version after that event.
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.
[+] [-] flohofwoe|2 years ago|reply
[+] [-] andsoitis|2 years ago|reply
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...
[+] [-] kwhinnery|2 years ago|reply
[+] [-] olestr|2 years ago|reply
[+] [-] rough-sea|2 years ago|reply
and use `deno compile` to ship it as a self contained binary
[+] [-] CyberDildonics|2 years ago|reply
[+] [-] paxys|2 years ago|reply
[+] [-] kiwicopple|2 years ago|reply
> 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...
[+] [-] throwawaymaths|2 years ago|reply
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.
[+] [-] oritsnile|2 years ago|reply
[+] [-] notnullorvoid|2 years ago|reply
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.
[+] [-] mehagar|2 years ago|reply
[+] [-] v3ss0n|2 years ago|reply
[+] [-] NTARelix|2 years ago|reply
> 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?
[1]: https://www.w3.org/TR/webgpu/
[+] [-] Jasper_|2 years ago|reply
[+] [-] flohofwoe|2 years ago|reply
https://github.com/gpuweb/gpuweb/wiki/Implementation-Status
[+] [-] FL33TW00D|2 years ago|reply
[+] [-] fulafel|2 years ago|reply
[+] [-] brundolf|2 years ago|reply
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.
[+] [-] jimmySixDOF|2 years ago|reply
[+] [-] FL33TW00D|2 years ago|reply
[+] [-] markdog12|2 years ago|reply
[+] [-] notnullorvoid|2 years ago|reply
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.