5 ms·

> "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? P

by 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.
      - 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.
- 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.
madsbuch 6y ago
Adding a not supported message is a design choice. The parent did not say that the library should not make a CPU implementation, just that the fallback should not be automatic. For some applications, it might be appropriate t fall back to the CPU, but change the problem resolution, for some applications it might be appropriate to not event attempt the run the software, and for some applications it might be appropriate to just run in CPU mode if GPU mode is not available. But I completely agree with the sentiment, that this should solely be the developers choice.
- Wowfunhappy 6y ago
  I think the developer should be able to explicitly disable the fallback, but I'd really like it to be enabled by default. I don't trust developers to think about weird hardware configurations, and I'd like the software to do what it can to (hopefully) keep working instead of just locking me out.
mikehollinger 6y ago
> "Personally, I would hate to use software which tells me to upgrade my GPU..." I think its a design decision for the underlying library. Is the behavior configurable, or "hidden" from the the user? Is the fallback configurable on a library-wide basis, or a per-kernel basis? If you're writing or testing code and trying to make it work, you want it to explode in an elegant-ish manner, and tell you what to fix. If you're shipping code, you want control over how it fails, and you might want different things. What are my options? There's probably cases where a graceful or semi-graceful fallback would work. However, there's cases where the time spent in CPU mode would be embarrassingly long - to the point where your options really are "show a message" or "disable the function." I'm with the OP here - the caller should have a say in the situation which will make the behavior predictable as software or hardware changes.

by gitgud 6y ago

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

madsbuch 6y ago

Adding a not supported message is a design choice. The parent did not say that the library should not make a CPU implementation, just that the fallback should not be automatic. For some applications, it might be appropriate t fall back to the CPU, but change the problem resolution, for some applications it might be appropriate to not event attempt the run the software, and for some applications it might be appropriate to just run in CPU mode if GPU mode is not available. But I completely agree with the sentiment, that this should solely be the developers choice.

Wowfunhappy 6y ago
I think the developer should be able to explicitly disable the fallback, but I'd really like it to be enabled by default. I don't trust developers to think about weird hardware configurations, and I'd like the software to do what it can to (hopefully) keep working instead of just locking me out.

mikehollinger 6y ago

> "Personally, I would hate to use software which tells me to upgrade my GPU..." I think its a design decision for the underlying library. Is the behavior configurable, or "hidden" from the the user? Is the fallback configurable on a library-wide basis, or a per-kernel basis? If you're writing or testing code and trying to make it work, you want it to explode in an elegant-ish manner, and tell you what to fix. If you're shipping code, you want control over how it fails, and you might want different things. What are my options? There's probably cases where a graceful or semi-graceful fallback would work. However, there's cases where the time spent in CPU mode would be embarrassingly long - to the point where your options really are "show a message" or "disable the function." I'm with the OP here - the caller should have a say in the situation which will make the behavior predictable as software or hardware changes.