5 ms·

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.
    - Jasper_ 6y ago
      I have to test for SwiftShader in my web game. Whenever Chrome gets a bit upset with the GPU it will silently fall back and make the game 10x as slow and I get a bunch of support requests. Putting in a check and telling people to restart Chrome has reduced my support workload a ton.
    - jlokier 6y ago
      Detecting WebGL will not tell you what is needed. I just tried a WebGL demo, and got wildly different results depending on the browser, and which GPU is active at the time the demo started. Results varied between: - Smooth and good looking - Good looking but <1fps. Turning off GPU features would have been the better thing to do. - Noisy, corrupt-looking pixels over half the image because calculations were producing incorrect numerical results; it looked like overflow or something. At least it's possible to detect a low frame rate and, eventually, compensate by reducing features and/or resolution. But that's still annoyingly slow (it will take a few seconds to detect). Bad calculations are a bigger problem, as it's hard to anticipate what kind of bad to look for and how to detect it.
      - rewq4321 6y ago
        > I just tried a WebGL demo, and got wildly different results depending on the browser That's not a problem with the API, that's a problem with one or more of your browsers. Bench-marking your code during init to choose the best algorithm is a very sane thing to do if you know your users' machines/browsers may have different capabilities. We're talking about extra fractions of a second of load time. The alternative is to expose a bunch of details about what's underneath the browser, which would probably not fit with the goals of the web - it being a sort of abstraction layer over all the operating systems and devices.
        jlokier 6y ago
        I agree when it comes to benchmarking for speed in WebGL. It's much more of a pain when calculations come out wrong though. It's hard to anticipate all the ways that might happen, check for them, and then find workarounds when you don't have the hardware where they go wrong. As noted in this comment https://news.ycombinator.com/item?id=24026914 https://news.ycombinator.com/item?id=24026914 some of these problems appear to be browser-independent. Bad calculations can ruin a game, not just due to visual glitches, but by revealing things that should be hidden, for example seeing through holes in walls caused by glitches.
rumanator 6y ago
> Failing seemed reasonable to me, because my context around software fallback translates to “1 or 2 fps if you are lucky”. Arguably I prefer to have the option to use software that underperforms than to not be able use it all all, specially if performance is not that critical.
- Aeolun 6y ago
  I don’t think software that runs at 2fps can be described as ‘underperforms’, that’s just ‘unusable’
  - rumanator 6y ago
    The "2fps" example was an arbitrary hyperbole that by itself is worth nothing as a claim or statement. Moreover, it's not up to you to decide what's acceptable or not to a 3rd party, specially if your claim is being made to justify choosing between being able to use something that performs below par or not be able to use it at all.
  - fulafel 6y ago
    Depends on the app entirely, for some things 2 fps is fine.
  - wtracy 6y ago
    Being able to run two images per second through a post-processing and/or computer vision pipeline still sounds pretty useful to me. Shoot, Blender still supports users without accelerated graphics. (Or did five years ago, things may have changed.)
- masklinn 6y ago
  Just as arguably that option should be an explicit opt-in by the application developer.
- murgindrag 6y ago
  Handling this gracefully would mean the developer can make that decision, explicitly. Ideally, the last piece of code I was working on would: 1. Detect GPU acceleration 2. With acceleration, enable fancy bells-and-whistles, with animations and effects 3. Without acceleration, fall back to good-old-fashioned mode, with flat HTML A lot of this depends on what YOUR software does. Is it speeding up a spreadsheet (which will probably work fine in CPU)? Is it adding fancier shaders to a video game? Explicit beats implicit. The library should support CPU and GPU, without a doubt, but the user of the library should make the decision of what to do if GPU isn't found.
elondaits 6y ago
GPU is used for other things besides rendering animations... AI for instance. In many contexts you want to perform the calculations, even without acceleration.
- cellularmitosis 6y ago
  I agree, but the parent was specifically talking about OpenGL software fall-backs.
jcelerier 6y ago
that's 2005 software fallback performance. We're in 2020, LLVMPipe can easily give you 15-25 fps for simple games, which is very decent for a fallback option. e.g. here's xonotic running on it on my laptop in full hd (i7-8750H): https://streamable.com/luxfv1 https://streamable.com/luxfv1 if I downgrade to 720p it's definitely playable.
Wowfunhappy 6y ago
Maybe on today's hardware, but what if I'm running this software 15 years from now? At which time, btw, I'm more likely to be forced to use a VM, or a similar solution where software rendering is the only option.

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.
  - Jasper_ 6y ago
    I have to test for SwiftShader in my web game. Whenever Chrome gets a bit upset with the GPU it will silently fall back and make the game 10x as slow and I get a bunch of support requests. Putting in a check and telling people to restart Chrome has reduced my support workload a ton.
  - jlokier 6y ago
    Detecting WebGL will not tell you what is needed. I just tried a WebGL demo, and got wildly different results depending on the browser, and which GPU is active at the time the demo started. Results varied between: - Smooth and good looking - Good looking but <1fps. Turning off GPU features would have been the better thing to do. - Noisy, corrupt-looking pixels over half the image because calculations were producing incorrect numerical results; it looked like overflow or something. At least it's possible to detect a low frame rate and, eventually, compensate by reducing features and/or resolution. But that's still annoyingly slow (it will take a few seconds to detect). Bad calculations are a bigger problem, as it's hard to anticipate what kind of bad to look for and how to detect it.
    - rewq4321 6y ago
      > I just tried a WebGL demo, and got wildly different results depending on the browser That's not a problem with the API, that's a problem with one or more of your browsers. Bench-marking your code during init to choose the best algorithm is a very sane thing to do if you know your users' machines/browsers may have different capabilities. We're talking about extra fractions of a second of load time. The alternative is to expose a bunch of details about what's underneath the browser, which would probably not fit with the goals of the web - it being a sort of abstraction layer over all the operating systems and devices.
      - jlokier 6y ago
        I agree when it comes to benchmarking for speed in WebGL. It's much more of a pain when calculations come out wrong though. It's hard to anticipate all the ways that might happen, check for them, and then find workarounds when you don't have the hardware where they go wrong. As noted in this comment https://news.ycombinator.com/item?id=24026914 https://news.ycombinator.com/item?id=24026914 some of these problems appear to be browser-independent. Bad calculations can ruin a game, not just due to visual glitches, but by revealing things that should be hidden, for example seeing through holes in walls caused by glitches.

rumanator 6y ago

> Failing seemed reasonable to me, because my context around software fallback translates to “1 or 2 fps if you are lucky”. Arguably I prefer to have the option to use software that underperforms than to not be able use it all all, specially if performance is not that critical.

Aeolun 6y ago
I don’t think software that runs at 2fps can be described as ‘underperforms’, that’s just ‘unusable’
- rumanator 6y ago
  The "2fps" example was an arbitrary hyperbole that by itself is worth nothing as a claim or statement. Moreover, it's not up to you to decide what's acceptable or not to a 3rd party, specially if your claim is being made to justify choosing between being able to use something that performs below par or not be able to use it at all.
- fulafel 6y ago
  Depends on the app entirely, for some things 2 fps is fine.
- wtracy 6y ago
  Being able to run two images per second through a post-processing and/or computer vision pipeline still sounds pretty useful to me. Shoot, Blender still supports users without accelerated graphics. (Or did five years ago, things may have changed.)
masklinn 6y ago
Just as arguably that option should be an explicit opt-in by the application developer.
murgindrag 6y ago
Handling this gracefully would mean the developer can make that decision, explicitly. Ideally, the last piece of code I was working on would: 1. Detect GPU acceleration 2. With acceleration, enable fancy bells-and-whistles, with animations and effects 3. Without acceleration, fall back to good-old-fashioned mode, with flat HTML A lot of this depends on what YOUR software does. Is it speeding up a spreadsheet (which will probably work fine in CPU)? Is it adding fancier shaders to a video game? Explicit beats implicit. The library should support CPU and GPU, without a doubt, but the user of the library should make the decision of what to do if GPU isn't found.

elondaits 6y ago

GPU is used for other things besides rendering animations... AI for instance. In many contexts you want to perform the calculations, even without acceleration.

cellularmitosis 6y ago
I agree, but the parent was specifically talking about OpenGL software fall-backs.

jcelerier 6y ago

that's 2005 software fallback performance. We're in 2020, LLVMPipe can easily give you 15-25 fps for simple games, which is very decent for a fallback option. e.g. here's xonotic running on it on my laptop in full hd (i7-8750H): https://streamable.com/luxfv1 https://streamable.com/luxfv1 if I downgrade to 720p it's definitely playable.

Wowfunhappy 6y ago

Maybe on today's hardware, but what if I'm running this software 15 years from now? At which time, btw, I'm more likely to be forced to use a VM, or a similar solution where software rendering is the only option.