
GPU Accelerated JavaScript - DerCommodore
https://gpu.rocks/
======
sillysaurusx
_Graceful pure JavaScript fallback when GPU is not available._

This is a bad thing, not a happy thing to be advertised. Software fallback was
of the most frustrating parts of working with OpenGL circa 2010.

If you're making a hardware accelerated library, stop trying to make it
"gracefully" fail. Just fail! That way people can address the root problem.

On the other hand, as long as the library is sufficiently noisy about the fact
that it's in CPU mode, it seems fine. I just hope they don't follow OpenGL's
design decisions.

It's surprisingly hard to figure out the answer from the README:
[https://github.com/gpujs/gpu.js/#readme](https://github.com/gpujs/gpu.js/#readme)
There's a "How to check what's supported" section, but it's also "mostly for
unit tests."

~~~
crazygringo
I'm actually curious, given the massive speed difference between CPU and GPU:
can anyone here think of any situation where a fallback to CPU speed _would_
still be acceptable for a real-life application?

The only thing I can think of is simple image operations like a 5x speedup for
a Gaussian blur filter... but then I also wonder if you'd even bother writing
code to do it on the GPU in the first place.

~~~
dahart
> can anyone here think of any situation where a fallback to CPU speed would
> still be acceptable for a real-life application?

Sure, there are valid scenarios where the slower speed fallback is acceptable.
Note that I agree with the GP comment; fallback should be explicit not
automatic.

\- Developer adoption. Not everyone has a GPU, but with a fallback path
everyone can try it out and write code that will work on the fast path.

\- Application development. Along the same lines as developer adoption, not
every customer has a GPU either, so if I write an app I may want to let the
user try a new feature (with a warning that it’s slow) rather than tell them
they can’t use the feature at all until they upgrade their hardware.

\- Heterogeneous compute farms. I’m thinking in particular of render farms for
VFX and CG movies, as an example, how a render farm is large and may not be
full of GPU nodes due to cost. A fallback path allows time/perf to be balanced
against whatever the farm’s budget for GPU nodes is.

\- Test machines. Running automated end-to-end integration tests to check for
correctness doesn’t depend on speed, and if you’re renting your test machines,
it might be cheaper to fallback to CPU than to rent GPU nodes. Think Selenium
tests running on a bunch of AWS nodes, for example.

------
Jhsto
For what it's worth, HN might be interested to look into how programming a
simple WebGPU calculator works. I worked on one some time ago:
[https://laskin.live/](https://laskin.live/)

Source-code is here:
[https://github.com/Laged/laskin.live](https://github.com/Laged/laskin.live)

This way you can use some "better" API like Vulkan to run programs that are
written in the new SPIR-V intermediate representation. In general, if you are
interested in GPU programming, I would definitely look into WebGPU. The API is
much easier to get started than Vulkan is, and achieves the most basic things
required for simple GPGPU tasks (despite the fact that WebGPU can use Vulkan
as the GPU API driver).

Note that WebGPU needs a browser flag to be enabled, and is generally very
dangerous. It's possible to kernel panic operating systems on web page load,
despite the fact that you are using a web browser.

~~~
rewq4321
Implementation status for the major browsers here:
[https://github.com/gpuweb/gpuweb/wiki/Implementation-
Status](https://github.com/gpuweb/gpuweb/wiki/Implementation-Status)

This, along with WebAssembly (threads, SIMD, etc), are going to be a very big
deal in the next few years. The obvious use case is AAA games running in your
browser, but I think once we've got 80-90% of native speeds on the web,
basically all of the "client-heavy" apps (video processing, game dev tools,
etc.) are going to start migrating over too. Not really an interesting
prediction at this stage, since it already started happening way back in asm
days. IIRC photopea.com doesn't even use WASM at all, and it has excellent
performance on all sorts of image manipulation/encoding/etc tasks. Still, I
think there are exciting times ahead for those hacking on the web platform.

~~~
kllrnohj
> The obvious use case is AAA games running in your browser

Er, no? Why would an AAA game, which typically wants every ounce of
performance and control it can get, ever jump onto a web platform and lose all
of that? And in exchange get... nothing at all? And since modern consoles are
the same architecture & ISAs as gaming PCs are, why would they want to figure
out a WASM backend with lagging hardware support & high overhead when 100% of
their users are x86-64 with the entirely same set of SIMD features? And do
they just not run an anti-cheat or DRM system? Good luck with that sales
pitch.

It's not like you'll ever be able to click a link and just start playing a AAA
game locally in your browser, either, you need to pull several gigs of assets
first. And go through a login/paywall unless we're only talking F2P games
which are almost never AAA games.

This use case comes up a lot, but if (and that's a big if) it happens, AAA
games will be the _last_ thing to switch, not the first. More plausible first
users would be things like CAD & 3D modelling applications, which need high
performance but also don't have 80GB+ installs.

~~~
untog
Non-AAA games seem like a huge target as well. Just look at the Steam store.
The web would be a really interesting medium for indie games.

~~~
kllrnohj
> The web would be a really interesting medium for indie games.

It already was. Flash gaming was huge (so was embedded Java gaming such as
Runescape). It regressed rather heavily over the years, perhaps from mobile,
perhaps from regressions in the web's tech stack even, or perhaps just from
social changes. But unless it was web technology regressing, I don't see why
WASM + WebGPU would suddenly bring it back, either.

~~~
untog
> But unless it was web technology regressing

Arguably it was. I’d say we still don’t have something that rivals every
feature Flash provided.

------
0xfffafaCrash
This is cool and I am glad it exists as someone who works with nodejs often,
but if you’re doing heavy server side computations where serious
parallelization is actually important, I’m a little skeptical that investing
in having those computations in JS is likely to be a reasonable choice in many
cases outside of small hobby projects. I could be wrong, but I think the
performance compared to other alternatives also using parallelization via the
GPU would be very unfavorable and you also wouldn’t have rich complementary
libraries for this as a result of the low performance ceiling for JS in this
domain.

~~~
sillysaurusx
Those criticisms haven't really been true of JS for years. Google has invested
many dozens of millions to make JS fast. And GPU acceleration is largely
unrelated to the particular language that happens to drive the GPU.

If the critique is "static typing good, JS bad" then that's a fair argument.
But personally I'm excited to have something akin to a scripting language for
a GPU.

~~~
0xfffafaCrash
Javascript is now fast in the sense that V8 is good enough at the things you
are likely to do in the browser or in a typical node server. The very example
in this link of how a matrix of random numbers is to be generated is an
absolute joke compared to how this would be achieved in lower level languages.
Javascript’s lack of static typing doesn’t just affect DX but what performance
enhancements can be made. You don’t have direct access to memory and V8’s
optimizations just aren’t THAT helpful for this sort of thing. This is a large
part of the appeal of WebAssembly in the browser context. Even asm.js,
impressive as it is/was, doesn’t really compare favorably and what you see
here is clearly nothing like asmjs. I have a lot of love for JS and there are
many domains it does well in but unless you show numbers that prove otherwise,
I’m quite sure you are totally wrong here.

~~~
sillysaurusx
_You don’t have direct access to memory and V8’s optimizations just aren’t
THAT helpful for this sort of thing._

You do: ArrayBuffer works great.

 _I have a lot of love for JS and there are many domains it does well in but
unless you show numbers that prove otherwise, I’m quite sure you are totally
wrong here._

I speak from experience :) Here's a demo of Javascript doing what it's
unsuited for: buttery-smooth 60FPS on iOS
[https://twitter.com/theshawwn/status/1222280670908600321](https://twitter.com/theshawwn/status/1222280670908600321)

Voice recognition:
[https://twitter.com/theshawwn/status/1151613837264732167](https://twitter.com/theshawwn/status/1151613837264732167)

It's fair to say that writing a matrix multiply in pure JS might not be the
best way to deploy your production code. But curing that is a matter of "run
profiler, see clear hotspot, optimize hotspot." Especially now that you have
so many options for dropping down to a lower-level stack.

JS is merely the wrapper, in many cases.

~~~
dkersten
I always wonder when I see these demos: what is it like in a real world
workload?

I remember some years ago everyone was going nuts over how WebGL was able to
render a detailed model in the browser, native games are dead! Except it was a
single non-animated 3D model, in a simple or non-existent background. _real_
games had many animated models, in complex environments, with complex
interaction, physics, AI, audio and gameplay logic.

Ever since that comparison, I think, yeah, those demos look cool and indeed
silky smooth, but most are a single simple thing. Real workloads tend to be
much more complex: how does it fare with those?

(Of course if the vast majority of the processing time is in the GPU, then it
really doesn’t matter what language, fast or slow, you use to control or feed
it.)

~~~
untog
One recent innovation that (IMO) hasn’t got much attention is OffscreenCanvas.
Even with WebGL, JS has been sorely limited by the fact that it’s single
threaded. OffscreenCanvas lets you pass a drawing context off to a separate
thread, or multiple contexts to multiple threads even. There’s a whole lot of
potential there that I haven’t seen tapped yet (but I’ll admit I’m not very
clued into the kind of scenes you’d see making the most of this).

As ever, browser support matters. Chrome and Firefox: yes. Safari? No.

[https://bugs.webkit.org/show_bug.cgi?id=183720](https://bugs.webkit.org/show_bug.cgi?id=183720)

~~~
rikroots
I'm excited by the prospect of OffscreenCanvas, and yet at the same time I'm
not convinced that it's going to be massively useful for my canvas library[1].
The one area where it could have a big impact (I think) would be to run the OC
in a web worker alongside the bulk of the library's code, leaving the main
thread to deal with final canvas display, user interactions, etc. But to
implement that I'd need to recode the entire library from scratch.

At the moment I generate additional canvas elements in the code (in a pool,
for reuse) and use them without adding them to the DOM. I'm happy with the
resulting frame rates, and the flexibility the system gives me for creating
responsive, accessible canvas elements in the web page. This is all done using
a simple 2d context (even the bendy images code[2] is 2d, rendered in the main
thread). I've avoided WebGL and the whole GPU acceleration thing because
shaders scare me more than quaternions!

[1] - Scrawl-canvas -
[https://scrawl.rikweb.org.uk/](https://scrawl.rikweb.org.uk/)

[2] - Bendy images interactive demo -
[https://scrawl.rikweb.org.uk/demo/canvas-024.html](https://scrawl.rikweb.org.uk/demo/canvas-024.html)

------
lmeyerov
As noted by others, instead of the handcuffs of lowest-common-denominator, we
do GPU JS with best of class in node, where we get to play with Apache Arrow,
RAPIDS, etc. We now shim nodejs to PyData for GPU tech vs doing node-
opencl/cuda to get more GPU lib access, but I'd love to add a more direct
numba-equiv and serverless layer here as V8 is better in key ways than cpython
in many key ways here, and only a few glaring gaps afaict (gotchas in bigint /
large memory space / etc still smoothing, TBD for multigpu and networking
streaming.)

GPU JS and related frameworks are really 'browser GPU JS', and we find
predictability there low enough that we still handroll WebGL 1.0 instead of
them. When we shift, I'd hope it'll be for a webgl2+ (opencl2+...), but 10+
years later, I've stopped tracking the politics.

------
mark_l_watson
I like how easy it is to write a new GPU kernel function.

I have never done any GPU kernel programming but I might give this a try.

I wonder if TensorFlow.js is implemented in much the same way. TensorFlow.js
is fairly much awesome, largely because the examples are so well done, getting
up to speed is painless.

------
melbourne_mat
This could be useful for embarrassingly parallel workloads but 2 points:

\- the backend is OpenGL so it won't be as performant on NVIDIA hardware as
CUDA (NVIDIA don't like OpenGL)

\- I don't see any explicit GPU memory management so you might not be able to
setup a pipeline of operations which all operate GPU memory (aka the big
pipelines you see in ML). That would be another performance hit.

Having said that it looks like fun and I'm going to check it out!

~~~
modeless
> NVIDIA don't like OpenGL

Nvidia loves OpenGL. They are probably the single biggest supporter of OpenGL.
They have the best OpenGL driver in the industry. The president of Khronos is
an Nvidia employee, as is the chair of the OpenGL working group.

CUDA is faster than OpenGL because it exposes more Nvidia proprietary
features. GPU.js could add a CUDA backend for the Node version, but it
wouldn't be portable to the Web or non-Nvidia GPUs.

~~~
pjmlp
Kind of, while they do love OpenGL for the graphics workstation cards, they
are also the main hardware partner for DirectX design.

NVidia's OpenGL and Vulkan extensions are usually born as hardware support for
DirectX capabilities, and then trickle down as extensions for OpenGL/Vulkan.

Also their main rendering products, like Optix, are CUDA based actually.

------
messe
Neat project, but I'm slightly disappointed there's no link to run the
benchmark directly in my browser without installing anything.

~~~
jkoudys
Ran fine for me:
[https://gpu.rocks/#/benchmark](https://gpu.rocks/#/benchmark)

~~~
messe
Ah. I clicked on benchmark, but because I'd already scrolled down on the page
I was on, it remained scrolled and all I saw was the graph. Thanks.

~~~
underdeserver
Please edit your top-level comment.

EDIT: Apparently you can't. Sorry.

~~~
messe
I can't any more.

------
api
Seems like if it's possible to accelerate JS with a GPU it should be far more
possible to do it with a many-core CPU. This bodes well for the likely future
of dozens of X64 cores or even hundreds of ARM cores on a higher-end
desktop/laptop chip and hundreds to thousands on server chips.

------
Galanwe
I may be confused as I do not know much javascript, but the installation page
mentions a dependency on Mesa, is it relying on it to perform the actual work?
If so, I do not quite understand the debates here around avoiding OpenGL
design and fallback to software emulation.

------
vladoh
Since this supports doing image convolutions I guess it can be used to do
efficient CNN inference. Are there any examples doing that?

I see there are some other libraries to run deep learning networks in the
browser (like Tensorflow.js), but it seems they have some limitation regarding
the use of the GPU.

It may be interesting in pushing the boundaries of this project to get an
efficient and generic CNN library. They seem to not use CUDA, which may be a
limitation...

------
Natalie1Quinn
My point is that if you are using JS as a wrapper for a big black box of gpu
computations that are close to the metal then you are not really using JS in
any meaningful sense and can wrap anything else that has a much better library
ecosystem and performance qualities for anything that you’re not just getting
the gpu to crank out in a server context (which is implied by nodejs).

There’s the speed of generating inputs, the speed of transforming and passing
data at the input/output boundaries, and the ability to conveniently and
performantly work with data in memory natively (i.e. while not outsourcing the
computations elsewhere) that matters here. Is JS a great choice for any of
these things? Most importantly, the last thing? This library isn’t using
ArrayBuffers for setting up all data or working on the data in JS so even if
they work great for performance it seems totally irrelevant and let’s be
honest, if it were working with ArrayBuffers directly you would be so far away
from usual JS and any convenience JS offers, you might as well not be writing
JS.[https://www.bloggerzune.com/2020/05/follow-my-blog-with-
blog...](https://www.bloggerzune.com/2020/05/follow-my-blog-with-
bloglovin.html?m=1)

------
mpfundstein
really a bummer that they require function keywors so that the gpu function
can access this.threads ! Would have been cleaner IMO - and more modern
ideomatic - if the callback would have a parameter that would refer to the
gpu.

otherwise this stuff is AWESOME. it would be great if we could reduce our
dependency on python

~~~
jfkebwjsbx
What are you doing with Python that somehow this would help at all?

I am really curious, specially given there are many other languages out there
to move to vs js.

------
superkuh
Do you want exploits? Because exposing more and more bare metal OS
functionality to javascript and then running all javascript you receive
without a care in the world is how you get exploits.

And then once the exploits appear now the user is the danger for going to
those sites, or installing that add-on, so the control must be taken away from
the user. And so on with HTTPS only and no more accepting self signed certs so
everyone has to be leashed to a cert authority and ask for permission to host
a visitable website.

No, making the browser the OS is the path to loss of control and darkness.

~~~
SquareWheel
Do you have a specific criticism of their work, or are you just reacting to
the title?

~~~
superkuh
>You need to enable JavaScript to run this app.

Unfortunately the title is all that's available.

