17 ms·

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 frustra

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?

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?