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...
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.
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.
Maybe you have a different context.
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.
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.
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.
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.
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 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.
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.
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.
Shoot, Blender still supports users without accelerated graphics. (Or did five years ago, things may have changed.)
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.
If you're writing a spreadsheet, use a fallback to CPU. If you're writing a glitzy animation, turn it off.
e.g. here's xonotic running on it on my laptop in full hd (i7-8750H): https://streamable.com/luxfv1
if I downgrade to 720p it's definitely playable.