13 ms·

GPU Accelerated JavaScript

361 points by DerCommodore 6y ago

sillysaurusx 6y ago
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."
- tomashubelbauer 6y ago
  What are people going to do in the case of no support though? Fallback to CPU anyway. I don't think there's many problems where it's either that you compute on the GPU or you don't want the result at all. And given than, falling back to the CPU makes sense to me. Having to write that code myself would be annoying. I do agree though that there should be (if there isn't, IDK) an escape hatch for the rare case it may be needed. But I do think this is the right default.
  - sillysaurusx 6y ago
    I mean, look at the performance chart. CPU mode performance is a nice J curve with respect to "realistic workloads you'd actually want to GPU accelerate." I agree that having a CPU fallback is nice, but it's also pretty much the opposite of what you'd want to do in the field. Prediction: someone deploys this and doesn't notice it's incredibly slow for mysterious reasons, and then spends several hours to figure out that the right version of CUDA wasn't installed. ("Fail fast, fail loudly" is a nice way to ensure that doesn't happen.)
    - nabla9 6y ago
      Do you think having default notification that says "No GPU"[OK] that can be disabled or modified would be the way to solve it?
      - asdfasgasdgasdg 6y ago
        Typically you'd bubble this up as a rejected promise in JavaScript. Hopefully with a more detailed error message than "no GPU". "Failed while doing X" or "failed because of Y," where the messages contain actionable info, would be ideal. Then the application developer can decide what to do. I've never done front end development but I would probably want to request permission to gather telemetry, and, if granted, post the telemetry and the error to an error logging service. Then you could try to diagnose aggregated issues. You could also offer the option to export the telemetry to a zip file (hopefully the same format you send it to the error logger). Then the user could examine it themselves and have the option to provide it to you via another channel (support forum, email, etc.).
    - rumanator 6y ago
      > I agree that having a CPU fallback is nice, but it's also pretty much the opposite of what you'd want to do in the field. Do the opinions of potential users matter? Because most people aren't willing to waste money on unnecessary upgrades just because a developer wanted to assume everyone had mid/high-end hardware.
    - flywheel 6y ago
      >Prediction: someone deploys this and doesn't notice it's incredibly slow for mysterious reasons, and then spends several hours to figure out that the right version of CUDA wasn't installed. Why not just print out a message "Running in CPU mode" or "Running in GPU mode". There's no reason it has to be a mystery. The comments here tell me that programmers have a narrow idea of what other programmers should/would/could do with their software.
  - imtringued 6y ago
    Your software will gain a reputation of being slow and there will be nothing you can do about that.
  - dkersten 6y ago
    Sure, but in my anecdotal experience, things where you care about acceleration are next to unusable without acceleration and by silently (its ok to do it noisily) falling back to cpu, you just give the user (who doesn’t necessarily realise its using the fallback) the impression that your software is slow garbage.
  - Const-me 6y ago
    > What are people going to do in the case of no support though? Fix their GPU drivers or OSes. In a cloud, switch to GPU instance type. Compute shaders were introduced in Direct3D 11.0, on PCs the support for them is required for a decade now. Mobile devices were a bit later, but their upgrade cycles are faster, the support is good by now.
  - formerly_proven 6y ago
    A lot of software doesn't have a CPU fallback path, because (1) the no/unsupported GPU case is very rare (2) performance on the CPU will be too bad to be of any use.
- gitgud 6y ago
  > "stop trying to make it "gracefully" fail. Just fail! That way people can address the root problem." So the root problem is not having the right hardware? Personally, I would hate to use software which tells me to upgrade my GPU, especially when there's a software fallback which could have been implemented... albeit with poorer performance...
  - cellularmitosis 6y ago
    Failing seemed reasonable to me, because my context around software fallback translates to “1 or 2 fps if you are lucky”. Maybe you have a different context.
    - rewq4321 6y ago
      Yeah, GGP's take is not that interesting. It just depends on how much extra perf/value you get from the GPU vs the CPU. If the GPU gives you some nice fancy shading, but your game works fine without it, then GGP's suggestion to "just make it fail" is of course silly. Slight tangent: I think a lot of "tech hot takes" (and snarky SO comments) come from a lack of imagination outside our own experience. It's easy to forget that there is often a huge diversity of applications/use-cases for the languages/libraries/etc that we use.
      - MayeulC 6y ago
        > If the GPU gives you some nice fancy shading, but your game works fine without it, then GGP's suggestion to "just make it fail" is of course silly. Not really, that's actually the point being made: if you try to use the GPU with your fancy shaders, you'd rather have it fail noisily so that you can explicitly fallback to the CPU implementation without your fancy shaders, than the library silently falling back to rendering everything (including your expensive shaders) on the CPU.
        rewq4321 6y ago
        Then, so far as I can see, it's not even a un-interesting take, since you can easily detect WebGL support before running GPU.js. Perhaps this was difficult to do with OpenCL in 2010, but it's a non-issue here.
- futun 6y ago
  > stop trying to make it "gracefully" fail. Just fail! This is the web. Not a video game. Accessibility is mission critical.
- Const-me 6y ago
  Agree. Same for SIMD instructions, and video decoders. Too many libraries/frameworks are trying to software emulate what's not supported, and fail miserably because the emulation is not remotely fast enough.
  - namibj 6y ago
    Good example: youtube.com It doesn't realize that H.264 1080p60 works due to HW decoding, and falls back to VP9 480p30 because it ties 720p and up to HFR if it's an HFR video. Using `youtube-dl -F` will tell you that 480p, 720p30, 720p60, 1080p30, and 1080p60 are available in H.264, while only higher resolutions are gated behind VP9. Some videos (from 50 Hz countries) are p25/p50 instead, but iirc using the same format codes as the p30/p60 brothers.
- bananaface 6y ago
  Why not just make graceful failure a flag?
  - ape4 6y ago
    Or a function to check if GPU is available.
- crazygringo 6y ago
  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.
  - soylentgraham 6y ago
    With OpenCL, one of the big (massive) benefits was being able to choose to run a kernel on CPU or GPU. The main case where CPU ran a lot faster was random memory access.
  - rewq4321 6y ago
    > a 5x speedup [...] I also wonder if you'd even bother writing code to do it on the GPU in the first place A 5x speed-up is very significant in many applications! I've spent a bunch of energy on several projects just aiming for a 2x speed-up on GPUs - battling against SIMD and other optimisations on the CPU side. As for real-world examples: The tensforflow.js CPU back-end runs something like 10x slower than the WebGL back-end, and I've got some great mileage out of the CPU back-end in simple node.js apps that don't have a GPU attached to their server.
  - dahart 6y ago
    > 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.
- kllrnohj 6y ago
  100% agreed. One of the most annoying things about OpenCL was the automatic CPU fallback. Trying to figure out if I had it actually _working_ or not was a terrible first impression. It gave an output, sure, but was it slow because it was still hitting the CPU fallback? Had I failed to install the GPU driver I had attempted to install? Or was it slow because my kernel wasn't GPU-friendly? Or hit some slow path in OpenCL? Meanwhile CUDA, being entirely GPU only, was a breeze. Did I get an output? OK then yes I got the basics working. Now on to making it sing.
  - fulafel 6y ago
    Note that the GP was were talking about OpenGL, not OpenCL.
    - dapids 6y ago
      Yea, and they both have the same issues, your point is?
      - fulafel 6y ago
        The situation is completely different on OpenCL, as the other comments show.
  - klelatti 6y ago
    I really don't understand this - it's very easy to set which device (CPU / GPU) your OpenCL code is running on and to avoid running on the CPU if you don't want that. On the other hand the ability to test on GPU-less systems is very useful indeed. OpenCL has lots of faults but the ability to use a CPU with the appropriate drivers when a GPU isn't available surely isn't one of them.
    - andromeduck 6y ago
      FYI cuda has that too, so they're probably talking about default behavior.
- xwdv 6y ago
  I typically see developers get stuck in one of the 5 stages of error handling. Denial: There won’t be an error, no need to catch anything. If an error happens just keep running it’s fine. Anger: Fuck this shit! Just delete this code, there’s gotta be a better way, a better library, a better language! Bargaining: What about a graceful fall back? Or maybe some kind of user prompt, or perhaps make it a feature!? Depression: There’s nothing we can do about it, we’ve thought of everything. Acceptance: Crash the program.
- dan_can_code 6y ago
  I disagree. JavaScript historically has always offered backward compatibility. > Backwards compatibility is important because of the large number of browsers deployed and the wide variety of versions of those browsers [0]. This may be the reasoning behind offering backwards compatibility. Also, according to the GitHub page [1] the fallbacks are WebGL2, and WebGL 1, and if neither of those work, only then will it use the CPU when in the browser. I find this to be quite acceptable. After all, it is JavaScript! [0] https://stackoverflow.com/questions/4937245/why-is-javascript-backwards-compatible-to-a-fault/4937292#4937292 https://stackoverflow.com/questions/4937245/why-is-javascrip... [1] https://github.com/gpujs/gpu.js/wiki/Quick-Concepts#fallback https://github.com/gpujs/gpu.js/wiki/Quick-Concepts#fallback
- danShumway 6y ago
  Heavily disagree. The difference between the CPU and the GPU in practice will be the speed that your code runs. If you have an app where you literally can't run it on a CPU, then there are probably going to be a few older and under-powered GPUs that also will be too slow. In which case, the correct thing for you to do is to do some very minor profiling of your application at runtime and show an error message or make adjustments based on the actual, real-world speed tests running on the real-world hardware sitting in front of the user. You shouldn't be policing the specific hardware, you should only be checking whether or not the hardware works. Setting up "allowlists" of what hardware we support is contrary to the philosophy and spirit of the web. Like you mention, there is a scenario where you might like to tell the user why the application is slow, and in that case, the ``GPU.isGPUSupported: boolean`` property seems sufficient to me. In general though, if your user wants to run your app on underpowered hardware, other than letting them know what the problem is, there is no reason for you not to get the heck out their way and let them do what they want to do. And it makes sense for the CPU fallback to be the default behavior, because the web is a general application platform for general, amateur programmers, and their defaults should allow them to fall into a pit of success. The idea that "the core library should fail, and the programmer should go out of their way to specify a custom CPU fallback alongside their original code", is just naive. Developers won't do that, the default setting should be the version that works for the most people. If you have a GPU accelerated application where it's genuinely preferable to just crash the entire application instead of letting it run slower, and if for some reason you can't do profiling instead of blindly assuming that all GPUs will be fast enough to run your application, then you can go out of your way to specify your own fail conditions. But that shouldn't be the default. By default, apps should work. The way that 90% of programmers will use this library is to have a normal application that has a few expensive operations that benefit from the GPU. For nearly all of those developers, having a default fallback to a slower implementation is the right choice. The 10% of developers that fall into the exception can manually detect slow hardware and code their own response.
  - karmakaze 6y ago
    > let them do what they want to do That's the thing. Sometimes it is specifically to use the GPU in which case a silent fallback isn't desired. It's fine for the software to include a CPU mode but make it an actual mode and and not always fallback so the user can specify 'what they want to do'.
- rafaelturk 6y ago
  Web is hard, is the most hostile hardware environment, ie Android fragmentation. What you're suggesting will only be feasible in a predictable hardware ecosystem. So what you're suggesting is that users without GPUs will break. I will take a side and pick the user this JavaScript fallback seems to me a good design choice.
  - riquito 6y ago
    Removing magic behaviour doesn't imply removing the functionality
- flywheel 6y ago
  >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. No. I want my code to run locally sometimes (possibly with a GPU), and sometimes I run the same code across hundreds of EC2 instances or just 1 instance, and I have good reasons for that. Sometimes a machine doesn't have a GPU, but I still want that code to run on it. The "bad thing" is imagining you know every possible use of javascript, and then telling other people about how they should be running javascript (or any language).
- jordache 6y ago
  Why is fallback so bad? As long as you gain insight into the operational mode, then you can decide on how to react to the situation. Perhaps you can fallback to a less demanding mode - process smaller dataset, or a less complex dataset... options are nice!
- gigatexal 6y ago
  Would a log message saying “not using the GPU, unable to find GPU” help?
0xfffafaCrash 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      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.
messe 6y ago
Neat project, but I'm slightly disappointed there's no link to run the benchmark directly in my browser without installing anything.
- classified 6y ago
  Is there no JavaScript implementation of a GPU that runs in the browser yet?
- jkoudys 6y ago
  Ran fine for me: https://gpu.rocks/#/benchmark https://gpu.rocks/#/benchmark
  - messe 6y ago
    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 6y ago
      Please edit your top-level comment. EDIT: Apparently you can't. Sorry.
      - messe 6y ago
        I can't any more.
  - mAritz 6y ago
    That benchmark seems a little bit problematic to me. When I click the benchmark button with matrix size 101 and iterations 5 the resulting score for GPU varies between 12k, 20k, 60k and Infinity.
melbourne_mat 6y ago
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!
- murgindrag 6y ago
  Speaking from my own personal use, 9 times out of 10, the 10x-30x speedup of going CPU to GPU is what I'm looking for. The extra 1.5-2x speedup at the end is not something I care about. I think this is the major hold-up to more GPGPU adoption. NVidia does an amazing job tweaking libraries for ultrafast performance for Torch/TensorFlow/video games, where it really does matter. In the process, they miss everyone else who has embarrassingly parallel problems, but where it's just not worth the time to code up different versions for CUDA and OpenCL (or whatever ATI/Intel happen to be swinging that week). I think if they did this /well/, they'd take over Intel as the major value-add in computers.
  - llukas 6y ago
    Did you check OpenACC out?
- modeless 6y ago
  > 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 6y ago
    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.
vladoh 6y ago
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...
Jhsto 6y ago
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 6y ago
  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 6y ago
    > 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.
mpfundstein 6y ago
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 6y ago
  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.
mark_l_watson 6y ago
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.
superkuh 6y ago
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 6y ago
  Do you have a specific criticism of their work, or are you just reacting to the title?
  - superkuh 6y ago
    >You need to enable JavaScript to run this app. Unfortunately the title is all that's available.
deleted 6y ago
[deleted]
Natalie1Quinn 6y ago
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-bloglovin.html?m=1 https://www.bloggerzune.com/2020/05/follow-my-blog-with-blog...
Galanwe 6y ago
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.
api 6y ago
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.
lmeyerov 6y ago
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.

361 points by DerCommodore 6y ago

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."

tomashubelbauer 6y ago
What are people going to do in the case of no support though? Fallback to CPU anyway. I don't think there's many problems where it's either that you compute on the GPU or you don't want the result at all. And given than, falling back to the CPU makes sense to me. Having to write that code myself would be annoying. I do agree though that there should be (if there isn't, IDK) an escape hatch for the rare case it may be needed. But I do think this is the right default.
- sillysaurusx 6y ago
  I mean, look at the performance chart. CPU mode performance is a nice J curve with respect to "realistic workloads you'd actually want to GPU accelerate." I agree that having a CPU fallback is nice, but it's also pretty much the opposite of what you'd want to do in the field. Prediction: someone deploys this and doesn't notice it's incredibly slow for mysterious reasons, and then spends several hours to figure out that the right version of CUDA wasn't installed. ("Fail fast, fail loudly" is a nice way to ensure that doesn't happen.)
  - nabla9 6y ago
    Do you think having default notification that says "No GPU"[OK] that can be disabled or modified would be the way to solve it?
    - asdfasgasdgasdg 6y ago
      Typically you'd bubble this up as a rejected promise in JavaScript. Hopefully with a more detailed error message than "no GPU". "Failed while doing X" or "failed because of Y," where the messages contain actionable info, would be ideal. Then the application developer can decide what to do. I've never done front end development but I would probably want to request permission to gather telemetry, and, if granted, post the telemetry and the error to an error logging service. Then you could try to diagnose aggregated issues. You could also offer the option to export the telemetry to a zip file (hopefully the same format you send it to the error logger). Then the user could examine it themselves and have the option to provide it to you via another channel (support forum, email, etc.).
  - rumanator 6y ago
    > I agree that having a CPU fallback is nice, but it's also pretty much the opposite of what you'd want to do in the field. Do the opinions of potential users matter? Because most people aren't willing to waste money on unnecessary upgrades just because a developer wanted to assume everyone had mid/high-end hardware.
  - flywheel 6y ago
    >Prediction: someone deploys this and doesn't notice it's incredibly slow for mysterious reasons, and then spends several hours to figure out that the right version of CUDA wasn't installed. Why not just print out a message "Running in CPU mode" or "Running in GPU mode". There's no reason it has to be a mystery. The comments here tell me that programmers have a narrow idea of what other programmers should/would/could do with their software.
- imtringued 6y ago
  Your software will gain a reputation of being slow and there will be nothing you can do about that.
- dkersten 6y ago
  Sure, but in my anecdotal experience, things where you care about acceleration are next to unusable without acceleration and by silently (its ok to do it noisily) falling back to cpu, you just give the user (who doesn’t necessarily realise its using the fallback) the impression that your software is slow garbage.
- Const-me 6y ago
  > What are people going to do in the case of no support though? Fix their GPU drivers or OSes. In a cloud, switch to GPU instance type. Compute shaders were introduced in Direct3D 11.0, on PCs the support for them is required for a decade now. Mobile devices were a bit later, but their upgrade cycles are faster, the support is good by now.
- formerly_proven 6y ago
  A lot of software doesn't have a CPU fallback path, because (1) the no/unsupported GPU case is very rare (2) performance on the CPU will be too bad to be of any use.
gitgud 6y ago
> "stop trying to make it "gracefully" fail. Just fail! That way people can address the root problem." So the root problem is not having the right hardware? Personally, I would hate to use software which tells me to upgrade my GPU, especially when there's a software fallback which could have been implemented... albeit with poorer performance...
- cellularmitosis 6y ago
  Failing seemed reasonable to me, because my context around software fallback translates to “1 or 2 fps if you are lucky”. Maybe you have a different context.
  - rewq4321 6y ago
    Yeah, GGP's take is not that interesting. It just depends on how much extra perf/value you get from the GPU vs the CPU. If the GPU gives you some nice fancy shading, but your game works fine without it, then GGP's suggestion to "just make it fail" is of course silly. Slight tangent: I think a lot of "tech hot takes" (and snarky SO comments) come from a lack of imagination outside our own experience. It's easy to forget that there is often a huge diversity of applications/use-cases for the languages/libraries/etc that we use.
    - MayeulC 6y ago
      > If the GPU gives you some nice fancy shading, but your game works fine without it, then GGP's suggestion to "just make it fail" is of course silly. Not really, that's actually the point being made: if you try to use the GPU with your fancy shaders, you'd rather have it fail noisily so that you can explicitly fallback to the CPU implementation without your fancy shaders, than the library silently falling back to rendering everything (including your expensive shaders) on the CPU.
      - rewq4321 6y ago
        Then, so far as I can see, it's not even a un-interesting take, since you can easily detect WebGL support before running GPU.js. Perhaps this was difficult to do with OpenCL in 2010, but it's a non-issue here.
futun 6y ago
> stop trying to make it "gracefully" fail. Just fail! This is the web. Not a video game. Accessibility is mission critical.
Const-me 6y ago
Agree. Same for SIMD instructions, and video decoders. Too many libraries/frameworks are trying to software emulate what's not supported, and fail miserably because the emulation is not remotely fast enough.
- namibj 6y ago
  Good example: youtube.com It doesn't realize that H.264 1080p60 works due to HW decoding, and falls back to VP9 480p30 because it ties 720p and up to HFR if it's an HFR video. Using `youtube-dl -F` will tell you that 480p, 720p30, 720p60, 1080p30, and 1080p60 are available in H.264, while only higher resolutions are gated behind VP9. Some videos (from 50 Hz countries) are p25/p50 instead, but iirc using the same format codes as the p30/p60 brothers.
bananaface 6y ago
Why not just make graceful failure a flag?
- ape4 6y ago
  Or a function to check if GPU is available.
crazygringo 6y ago
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.
- soylentgraham 6y ago
  With OpenCL, one of the big (massive) benefits was being able to choose to run a kernel on CPU or GPU. The main case where CPU ran a lot faster was random memory access.
- rewq4321 6y ago
  > a 5x speedup [...] I also wonder if you'd even bother writing code to do it on the GPU in the first place A 5x speed-up is very significant in many applications! I've spent a bunch of energy on several projects just aiming for a 2x speed-up on GPUs - battling against SIMD and other optimisations on the CPU side. As for real-world examples: The tensforflow.js CPU back-end runs something like 10x slower than the WebGL back-end, and I've got some great mileage out of the CPU back-end in simple node.js apps that don't have a GPU attached to their server.
- dahart 6y ago
  > 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.
kllrnohj 6y ago
100% agreed. One of the most annoying things about OpenCL was the automatic CPU fallback. Trying to figure out if I had it actually _working_ or not was a terrible first impression. It gave an output, sure, but was it slow because it was still hitting the CPU fallback? Had I failed to install the GPU driver I had attempted to install? Or was it slow because my kernel wasn't GPU-friendly? Or hit some slow path in OpenCL? Meanwhile CUDA, being entirely GPU only, was a breeze. Did I get an output? OK then yes I got the basics working. Now on to making it sing.
- fulafel 6y ago
  Note that the GP was were talking about OpenGL, not OpenCL.
  - dapids 6y ago
    Yea, and they both have the same issues, your point is?
    - fulafel 6y ago
      The situation is completely different on OpenCL, as the other comments show.
- klelatti 6y ago
  I really don't understand this - it's very easy to set which device (CPU / GPU) your OpenCL code is running on and to avoid running on the CPU if you don't want that. On the other hand the ability to test on GPU-less systems is very useful indeed. OpenCL has lots of faults but the ability to use a CPU with the appropriate drivers when a GPU isn't available surely isn't one of them.
  - andromeduck 6y ago
    FYI cuda has that too, so they're probably talking about default behavior.
xwdv 6y ago
I typically see developers get stuck in one of the 5 stages of error handling. Denial: There won’t be an error, no need to catch anything. If an error happens just keep running it’s fine. Anger: Fuck this shit! Just delete this code, there’s gotta be a better way, a better library, a better language! Bargaining: What about a graceful fall back? Or maybe some kind of user prompt, or perhaps make it a feature!? Depression: There’s nothing we can do about it, we’ve thought of everything. Acceptance: Crash the program.
dan_can_code 6y ago
I disagree. JavaScript historically has always offered backward compatibility. > Backwards compatibility is important because of the large number of browsers deployed and the wide variety of versions of those browsers [0]. This may be the reasoning behind offering backwards compatibility. Also, according to the GitHub page [1] the fallbacks are WebGL2, and WebGL 1, and if neither of those work, only then will it use the CPU when in the browser. I find this to be quite acceptable. After all, it is JavaScript! [0] https://stackoverflow.com/questions/4937245/why-is-javascript-backwards-compatible-to-a-fault/4937292#4937292 https://stackoverflow.com/questions/4937245/why-is-javascrip... [1] https://github.com/gpujs/gpu.js/wiki/Quick-Concepts#fallback https://github.com/gpujs/gpu.js/wiki/Quick-Concepts#fallback
danShumway 6y ago
Heavily disagree. The difference between the CPU and the GPU in practice will be the speed that your code runs. If you have an app where you literally can't run it on a CPU, then there are probably going to be a few older and under-powered GPUs that also will be too slow. In which case, the correct thing for you to do is to do some very minor profiling of your application at runtime and show an error message or make adjustments based on the actual, real-world speed tests running on the real-world hardware sitting in front of the user. You shouldn't be policing the specific hardware, you should only be checking whether or not the hardware works. Setting up "allowlists" of what hardware we support is contrary to the philosophy and spirit of the web. Like you mention, there is a scenario where you might like to tell the user why the application is slow, and in that case, the ``GPU.isGPUSupported: boolean`` property seems sufficient to me. In general though, if your user wants to run your app on underpowered hardware, other than letting them know what the problem is, there is no reason for you not to get the heck out their way and let them do what they want to do. And it makes sense for the CPU fallback to be the default behavior, because the web is a general application platform for general, amateur programmers, and their defaults should allow them to fall into a pit of success. The idea that "the core library should fail, and the programmer should go out of their way to specify a custom CPU fallback alongside their original code", is just naive. Developers won't do that, the default setting should be the version that works for the most people. If you have a GPU accelerated application where it's genuinely preferable to just crash the entire application instead of letting it run slower, and if for some reason you can't do profiling instead of blindly assuming that all GPUs will be fast enough to run your application, then you can go out of your way to specify your own fail conditions. But that shouldn't be the default. By default, apps should work. The way that 90% of programmers will use this library is to have a normal application that has a few expensive operations that benefit from the GPU. For nearly all of those developers, having a default fallback to a slower implementation is the right choice. The 10% of developers that fall into the exception can manually detect slow hardware and code their own response.
- karmakaze 6y ago
  > let them do what they want to do That's the thing. Sometimes it is specifically to use the GPU in which case a silent fallback isn't desired. It's fine for the software to include a CPU mode but make it an actual mode and and not always fallback so the user can specify 'what they want to do'.
rafaelturk 6y ago
Web is hard, is the most hostile hardware environment, ie Android fragmentation. What you're suggesting will only be feasible in a predictable hardware ecosystem. So what you're suggesting is that users without GPUs will break. I will take a side and pick the user this JavaScript fallback seems to me a good design choice.
- riquito 6y ago
  Removing magic behaviour doesn't imply removing the functionality
flywheel 6y ago
>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. No. I want my code to run locally sometimes (possibly with a GPU), and sometimes I run the same code across hundreds of EC2 instances or just 1 instance, and I have good reasons for that. Sometimes a machine doesn't have a GPU, but I still want that code to run on it. The "bad thing" is imagining you know every possible use of javascript, and then telling other people about how they should be running javascript (or any language).
jordache 6y ago
Why is fallback so bad? As long as you gain insight into the operational mode, then you can decide on how to react to the situation. Perhaps you can fallback to a less demanding mode - process smaller dataset, or a less complex dataset... options are nice!
gigatexal 6y ago
Would a log message saying “not using the GPU, unable to find GPU” help?

0xfffafaCrash 6y ago

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 6y ago
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 6y ago
  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 6y ago
    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.

messe 6y ago

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

classified 6y ago
Is there no JavaScript implementation of a GPU that runs in the browser yet?
jkoudys 6y ago
Ran fine for me: https://gpu.rocks/#/benchmark https://gpu.rocks/#/benchmark
- messe 6y ago
  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 6y ago
    Please edit your top-level comment. EDIT: Apparently you can't. Sorry.
    - messe 6y ago
      I can't any more.
- mAritz 6y ago
  That benchmark seems a little bit problematic to me. When I click the benchmark button with matrix size 101 and iterations 5 the resulting score for GPU varies between 12k, 20k, 60k and Infinity.

melbourne_mat 6y ago

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!

murgindrag 6y ago
Speaking from my own personal use, 9 times out of 10, the 10x-30x speedup of going CPU to GPU is what I'm looking for. The extra 1.5-2x speedup at the end is not something I care about. I think this is the major hold-up to more GPGPU adoption. NVidia does an amazing job tweaking libraries for ultrafast performance for Torch/TensorFlow/video games, where it really does matter. In the process, they miss everyone else who has embarrassingly parallel problems, but where it's just not worth the time to code up different versions for CUDA and OpenCL (or whatever ATI/Intel happen to be swinging that week). I think if they did this /well/, they'd take over Intel as the major value-add in computers.
- llukas 6y ago
  Did you check OpenACC out?
modeless 6y ago
> 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 6y ago
  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.

vladoh 6y ago

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...

Jhsto 6y ago

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 6y ago
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 6y ago
  > 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.

mpfundstein 6y ago

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 6y ago
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.

mark_l_watson 6y ago

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.

superkuh 6y ago

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 6y ago
Do you have a specific criticism of their work, or are you just reacting to the title?
- superkuh 6y ago
  >You need to enable JavaScript to run this app. Unfortunately the title is all that's available.

deleted 6y ago

[deleted]

Natalie1Quinn 6y ago

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-bloglovin.html?m=1 https://www.bloggerzune.com/2020/05/follow-my-blog-with-blog...

Galanwe 6y ago

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.

api 6y ago

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.

lmeyerov 6y ago

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.