4 ms·

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

> 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.
- admax88q 6y ago
  That's fair assuming that developers put in the effort to write the less fancy version. But if they don't I'd prefer to still have the option to run the software as written with worse performance.
  - murgindrag 6y ago
    No one's talking about taking that option away. All I'm saying is it should be an explicit option. When you initialize the library, you can pass a parameter. Or set a feature flag. Or whatnot. If you're writing a spreadsheet, use a fallback to CPU. If you're writing a glitzy animation, turn it off.

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.

admax88q 6y ago
That's fair assuming that developers put in the effort to write the less fancy version. But if they don't I'd prefer to still have the option to run the software as written with worse performance.
- murgindrag 6y ago
  No one's talking about taking that option away. All I'm saying is it should be an explicit option. When you initialize the library, you can pass a parameter. Or set a feature flag. Or whatnot. If you're writing a spreadsheet, use a fallback to CPU. If you're writing a glitzy animation, turn it off.