5 ms·

Deno 1.39: The Return of WebGPU

192 points by oritsnile 3y ago

kiwicopple 3y ago
This is exciting > 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-webgpu-api https://deno.com/blog/v1.8#experimental-support-for-the-webg...
- oritsnile 3y ago
  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.
- v3ss0n 3y ago
  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
  - mort96 3y ago
    "Languages with curly braces are categorically useless for data exploration" is certainly ... a take.
  - throwawaymaths 3y ago
    don't nobody tell him about this double bracket [[]] language called mathematica!
  - willio58 3y ago
    I don’t think even the creator of Python would agree with this..
  - test098 3y ago
    i've built an entire career building apps and tools in JS for data scientists to explore complex data. tons of companies pay lots and lots of money for this - i'm currently at a FAANG doing exactly this with data scientists.
  - mike_ivanov 3y ago
    Did you forget about R?
    - v3ss0n 3y ago
      yet it doesn't even have a comparable market share ( even tho whole ecosystem is dedicated for datascience)
- throwawaymaths 3y ago
  > 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.
  - jampekka 3y ago
    I'd love to use JS instead of Python for math/numerical stuff for many reasons, but without operator overloading it's just hell.
    - cnity 3y ago
      Interestingly I dislike Python for the exact same reason. Every time I look at a PR, I second guess every single operator and index. Does this attribute access carry a heavy penalty or side effects? Etc. I find it adds a large mental overhead to any given piece of code.
      - jampekka 3y ago
        Side effects on operator overload or attribute read are just really bad practice and is very rarely done. Do you second guess every identifier in C because it could be a preprocessor macro? Yeah, stupid overloading like C++ IO is a mess, but I haven't encountered much such abuse in Python.
        cnity 3y ago
        Fair points. I do find the scope of C macros to be far narrower than overloading, but you are right.
- mehagar 3y ago
  See also Web Neural Network API: https://www.w3.org/TR/webnn/ https://www.w3.org/TR/webnn/
- notnullorvoid 3y ago
  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.
flohofwoe 3y ago
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 :)
- olestr 3y ago
  The initial WebGPU Standard Library is such a promising step in this direction!
- rough-sea 3y ago
  excellent idea! and use `deno compile` to ship it as a self contained binary
- andsoitis 3y ago
  > integrate a minimal native system glue library into Deno have you tried denog (fork of deno which uses winit for Windowing and also has WebGPU support)? https://github.com/denogdev/denog 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-1400650492 https://github.com/gfx-rs/wgpu/pull/3265#issuecomment-140065...
  - flohofwoe 3y ago
    That's fantastic!
  - MuffinFlavored 3y ago
    I'm curious why they needed to fork Deno to achieve this. There wasn't a way to achieve this as like a library/3rd party package/wrapper or something? The fork is already ~1700 commits out of date with the original. How often would they sync, etc.?
    - lytedev 3y ago
markdog12 3y ago
> WebGPU is still considered unstable in Deno. To access it in Deno use the --unstable-webgpu flag
- notnullorvoid 3y ago
  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.
jimmySixDOF 3y ago
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 !
- FL33TW00D 3y ago
  Why were you skeptical of it originally? I wrote about this coming to pass over a year ago now: https://fleetwood.dev/posts/a-case-for-client-side-machine-learning https://fleetwood.dev/posts/a-case-for-client-side-machine-l...
NTARelix 3y ago
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? [1]: https://www.w3.org/TR/webgpu/ https://www.w3.org/TR/webgpu/
- flohofwoe 3y ago
  This might be a better page to get an idea what's the status in different browsers: https://github.com/gpuweb/gpuweb/wiki/Implementation-Status https://github.com/gpuweb/gpuweb/wiki/Implementation-Status
- fulafel 3y ago
  There seem to be no current 1.0 discussions yet on the GitHub prpject, seems possible it's a mistake at the Deno end.
- FL33TW00D 3y ago
  If you're using any Chromium based browser it's on your machine right now.
  - edflsafoiewq 3y ago
    The question is, is it still going to change?
    - flohofwoe 3y ago
      Minor things probably yes (for instance check the "What's new in WebGPU (Chrome xxx)" articles here: https://developer.chrome.com/docs/web-platform/webgpu https://developer.chrome.com/docs/web-platform/webgpu), breaking changes probably not.
- Jasper_ 3y ago
  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.
brundolf 3y ago
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.

192 points by oritsnile 3y ago

This is exciting > 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-webgpu-api https://deno.com/blog/v1.8#experimental-support-for-the-webg...

oritsnile 3y ago
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.
v3ss0n 3y ago
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
- mort96 3y ago
  "Languages with curly braces are categorically useless for data exploration" is certainly ... a take.
- throwawaymaths 3y ago
  don't nobody tell him about this double bracket [[]] language called mathematica!
- willio58 3y ago
  I don’t think even the creator of Python would agree with this..
- test098 3y ago
  i've built an entire career building apps and tools in JS for data scientists to explore complex data. tons of companies pay lots and lots of money for this - i'm currently at a FAANG doing exactly this with data scientists.
- mike_ivanov 3y ago
  Did you forget about R?
  - v3ss0n 3y ago
    yet it doesn't even have a comparable market share ( even tho whole ecosystem is dedicated for datascience)
throwawaymaths 3y ago
> 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.
- jampekka 3y ago
  I'd love to use JS instead of Python for math/numerical stuff for many reasons, but without operator overloading it's just hell.
  - cnity 3y ago
    Interestingly I dislike Python for the exact same reason. Every time I look at a PR, I second guess every single operator and index. Does this attribute access carry a heavy penalty or side effects? Etc. I find it adds a large mental overhead to any given piece of code.
    - jampekka 3y ago
      Side effects on operator overload or attribute read are just really bad practice and is very rarely done. Do you second guess every identifier in C because it could be a preprocessor macro? Yeah, stupid overloading like C++ IO is a mess, but I haven't encountered much such abuse in Python.
      - cnity 3y ago
        Fair points. I do find the scope of C macros to be far narrower than overloading, but you are right.
mehagar 3y ago
See also Web Neural Network API: https://www.w3.org/TR/webnn/ https://www.w3.org/TR/webnn/
notnullorvoid 3y ago
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.

flohofwoe 3y ago

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 :)

olestr 3y ago
The initial WebGPU Standard Library is such a promising step in this direction!
rough-sea 3y ago
excellent idea! and use `deno compile` to ship it as a self contained binary
andsoitis 3y ago
> integrate a minimal native system glue library into Deno have you tried denog (fork of deno which uses winit for Windowing and also has WebGPU support)? https://github.com/denogdev/denog 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-1400650492 https://github.com/gfx-rs/wgpu/pull/3265#issuecomment-140065...
- flohofwoe 3y ago
  That's fantastic!
- MuffinFlavored 3y ago
  I'm curious why they needed to fork Deno to achieve this. There wasn't a way to achieve this as like a library/3rd party package/wrapper or something? The fork is already ~1700 commits out of date with the original. How often would they sync, etc.?
  - lytedev 3y ago

markdog12 3y ago

> WebGPU is still considered unstable in Deno. To access it in Deno use the --unstable-webgpu flag

notnullorvoid 3y ago
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.

jimmySixDOF 3y ago

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 !

FL33TW00D 3y ago
Why were you skeptical of it originally? I wrote about this coming to pass over a year ago now: https://fleetwood.dev/posts/a-case-for-client-side-machine-learning https://fleetwood.dev/posts/a-case-for-client-side-machine-l...

NTARelix 3y ago

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? [1]: https://www.w3.org/TR/webgpu/ https://www.w3.org/TR/webgpu/

flohofwoe 3y ago
This might be a better page to get an idea what's the status in different browsers: https://github.com/gpuweb/gpuweb/wiki/Implementation-Status https://github.com/gpuweb/gpuweb/wiki/Implementation-Status
fulafel 3y ago
There seem to be no current 1.0 discussions yet on the GitHub prpject, seems possible it's a mistake at the Deno end.
FL33TW00D 3y ago
If you're using any Chromium based browser it's on your machine right now.
- edflsafoiewq 3y ago
  The question is, is it still going to change?
  - flohofwoe 3y ago
    Minor things probably yes (for instance check the "What's new in WebGPU (Chrome xxx)" articles here: https://developer.chrome.com/docs/web-platform/webgpu https://developer.chrome.com/docs/web-platform/webgpu), breaking changes probably not.
Jasper_ 3y ago
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.

brundolf 3y ago

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.