4 ms·

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

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.

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.