4 ms·

CUDA owns the industry. AMD has to step up with a good alternative to disrupt it. Any serious work is being done in CUDA and there are lots of resources for CUD

CUDA owns the industry. AMD has to step up with a good alternative to disrupt it. Any serious work is being done in CUDA and there are lots of resources for CUDA.

sdenton4 6y ago
(well, there is also 'serious' work being done with TPUs...)
shmerl 6y ago
You don't need to use CUDA for GPU programming, no? It's simply a lock-in. But I'm sure Nvidia was pushing it quite lot to make sure it's hard not to use it. But it clearly has to go. It's not healthy for the industry.
- atomlib 6y ago
  Are you trying to say Nvidia created a great framework for GPU compute so everyone is using it?
  - shmerl 6y ago
    Nvidia probably sponsored a lot of high level frameworks that only support CUDA, essentially poisoning them with lock-in.
    - atomlib 6y ago
      No, it did not. There are plenty of entirely independent benchmarks showcasing Nvidia's advantage. As far as I'm concerned Nvidia has honest and deserved reason to say they currently produce the best GPUs both for both gaming and compute workloads. Are you an unpaid AMD advocate or something? There's nothing inherently “clean” or morally right about buying AMD products.
      - shmerl 6y ago
        AMD apparently had asynchronous compute support in hardware when Nvidia didn't. And cryptocurrency miners bought AMD a lot more as well. I don't call lock-in shenanigans a fair advantage. And supporting lock-in is a slippery slope.
        pjmlp 6y ago
        That did not come with support for C++, Fortran, .NET, Java, graphical debuggers with ability to step through shader code, so bad luck.
      - hobofan 6y ago
        Though this is a snapshot from ~2015, I don't think anything has significantly changed since then: I developed a (more or less popular, though not in wide use) ML framework[0] back then. NVIDIA pretty quickly contacted us and offered to send a Titan X (top-of-the-line back then) our way. We also tried to make the framework work with OpenCL, but were severely limited in doing so. Mostly because Nvidia intentionally limits their GPUs to an older OpenCL version that has an uncompetitive featureset. They started doing that once they had a decent lead in the market over AMD. With that OpenCL was no longer vendor agnostic, but rather AMD-only, and you would always need to fully support both backends to support both vendors. Yes, Nvidia may produce the best GPUs right now and have great market and mindshare, but there is nothing "honest and deserved" about how they got there. [0]: https://github.com/autumnai/leaf https://github.com/autumnai/leaf
        pjmlp 6y ago
        The fact that OpenCL is stuck on a C dialect, while CUDA is a polyglot runtime already puts OpenCL out of the game for me. In fact it was thanks to this that Khronos finally woke up, but it was too late, and almost no one cares to target SPIR, while SYSCL just decided to go backend agnostic with the whole 1.2 => 3.0 rebranding. As for the rest, rules of the game.
        shmerl 6y ago
        Nvidia has been doing this anti-competitive junk for years. There is nothing honest and deserved about crooked practices. Today it should be easier to target compute queues with something like Vulkan though, which is a generic GPU API, not limited to graphics.
    - pjmlp 6y ago
      Nope, it is up to Khronos and other card vendors to actually offer tooling beyond stone age C dialects and printf style debugging. NVidia cannot be blamed for their incompetency.
    - fluffything 6y ago
      Somebody below mentions that nvidia donated free GPUs to the developers of these open source frameworks. Why didn't AMD do this as well? I thought AMD was strong on supporting open source.
- fluffything 6y ago
  > You don't need to use CUDA for GPU programming, no? No, you don't _need_ to use CUDA for GPU programming, you can use OpenCL or Vulkan or probably even PHP instead. I do, however, _want_ to use the best programming language for the task at hand. If that task is GPU programming, CUDA is the best language I know for that, much better than SyCL, OpenCL, Vulkan / OpenGL + shaders, etc. If these other technologies would be better, I would use them instead.
  - shmerl 6y ago
    CUDA can't be best if it's tied to a single GPU. It's DOA by definition. This idea of "a language that only works on this hardware" is out of some dinosaur lock-in handbook from the last century.
    - fluffything 6y ago
      CUDA compiles to CPUs, and AMD has support for CUDA via HIP. Not that this matters because your argument is flawed. The claim that CUDA is not worth using because it lacks portability, only holds, if there is hardware worth using that's not supported by CUDA. The only GPUs worth buying for compute are from nvidia and support CUDA, so your claim isn't true. The only thing you achieve today by not using CUDA is paying a huge price in development quality for portability that you can't use. The startup cemetery is filled with companies that made this trade-off and picked OpenCL just in case they wanted to use non-nvidia hardware. They were all killed by the velocity of their competitors that were using CUDA to deliver better products that payed the bills. The only people for which it might make sense to avoid CUDA are "non-professionals" (hobbyist, etc.). If you only want to use OpenCL to "learn OpenCL", then OpenCL is the right choice. But if you want to make money, then CUDA was the right choice 15 years ago and still is the right choice today. If that makes you angry, direct your anger properly. It isn't NVIDIA's fault that CUDA is really good. It is however, AMD's, Intel's, Apple's, Qualcomm, ARM's... fault that everything else _sucks hard_. Being angry at nvidia for delivering good products is just stupid. Its the other companies fault that they can't seem to be able to get their sh* together when it comes to GPU computing.
      - 6y ago

CUDA owns the industry. AMD has to step up with a good alternative to disrupt it. Any serious work is being done in CUDA and there are lots of resources for CUDA.

sdenton4 6y ago

(well, there is also 'serious' work being done with TPUs...)

shmerl 6y ago

You don't need to use CUDA for GPU programming, no? It's simply a lock-in. But I'm sure Nvidia was pushing it quite lot to make sure it's hard not to use it. But it clearly has to go. It's not healthy for the industry.

atomlib 6y ago
Are you trying to say Nvidia created a great framework for GPU compute so everyone is using it?
- shmerl 6y ago
  Nvidia probably sponsored a lot of high level frameworks that only support CUDA, essentially poisoning them with lock-in.
  - atomlib 6y ago
    No, it did not. There are plenty of entirely independent benchmarks showcasing Nvidia's advantage. As far as I'm concerned Nvidia has honest and deserved reason to say they currently produce the best GPUs both for both gaming and compute workloads. Are you an unpaid AMD advocate or something? There's nothing inherently “clean” or morally right about buying AMD products.
    - shmerl 6y ago
      AMD apparently had asynchronous compute support in hardware when Nvidia didn't. And cryptocurrency miners bought AMD a lot more as well. I don't call lock-in shenanigans a fair advantage. And supporting lock-in is a slippery slope.
      - pjmlp 6y ago
        That did not come with support for C++, Fortran, .NET, Java, graphical debuggers with ability to step through shader code, so bad luck.
    - hobofan 6y ago
      Though this is a snapshot from ~2015, I don't think anything has significantly changed since then: I developed a (more or less popular, though not in wide use) ML framework[0] back then. NVIDIA pretty quickly contacted us and offered to send a Titan X (top-of-the-line back then) our way. We also tried to make the framework work with OpenCL, but were severely limited in doing so. Mostly because Nvidia intentionally limits their GPUs to an older OpenCL version that has an uncompetitive featureset. They started doing that once they had a decent lead in the market over AMD. With that OpenCL was no longer vendor agnostic, but rather AMD-only, and you would always need to fully support both backends to support both vendors. Yes, Nvidia may produce the best GPUs right now and have great market and mindshare, but there is nothing "honest and deserved" about how they got there. [0]: https://github.com/autumnai/leaf https://github.com/autumnai/leaf
      - pjmlp 6y ago
        The fact that OpenCL is stuck on a C dialect, while CUDA is a polyglot runtime already puts OpenCL out of the game for me. In fact it was thanks to this that Khronos finally woke up, but it was too late, and almost no one cares to target SPIR, while SYSCL just decided to go backend agnostic with the whole 1.2 => 3.0 rebranding. As for the rest, rules of the game.
      - shmerl 6y ago
        Nvidia has been doing this anti-competitive junk for years. There is nothing honest and deserved about crooked practices. Today it should be easier to target compute queues with something like Vulkan though, which is a generic GPU API, not limited to graphics.
  - pjmlp 6y ago
    Nope, it is up to Khronos and other card vendors to actually offer tooling beyond stone age C dialects and printf style debugging. NVidia cannot be blamed for their incompetency.
  - fluffything 6y ago
    Somebody below mentions that nvidia donated free GPUs to the developers of these open source frameworks. Why didn't AMD do this as well? I thought AMD was strong on supporting open source.
fluffything 6y ago
> You don't need to use CUDA for GPU programming, no? No, you don't _need_ to use CUDA for GPU programming, you can use OpenCL or Vulkan or probably even PHP instead. I do, however, _want_ to use the best programming language for the task at hand. If that task is GPU programming, CUDA is the best language I know for that, much better than SyCL, OpenCL, Vulkan / OpenGL + shaders, etc. If these other technologies would be better, I would use them instead.
- shmerl 6y ago
  CUDA can't be best if it's tied to a single GPU. It's DOA by definition. This idea of "a language that only works on this hardware" is out of some dinosaur lock-in handbook from the last century.
  - fluffything 6y ago
    CUDA compiles to CPUs, and AMD has support for CUDA via HIP. Not that this matters because your argument is flawed. The claim that CUDA is not worth using because it lacks portability, only holds, if there is hardware worth using that's not supported by CUDA. The only GPUs worth buying for compute are from nvidia and support CUDA, so your claim isn't true. The only thing you achieve today by not using CUDA is paying a huge price in development quality for portability that you can't use. The startup cemetery is filled with companies that made this trade-off and picked OpenCL just in case they wanted to use non-nvidia hardware. They were all killed by the velocity of their competitors that were using CUDA to deliver better products that payed the bills. The only people for which it might make sense to avoid CUDA are "non-professionals" (hobbyist, etc.). If you only want to use OpenCL to "learn OpenCL", then OpenCL is the right choice. But if you want to make money, then CUDA was the right choice 15 years ago and still is the right choice today. If that makes you angry, direct your anger properly. It isn't NVIDIA's fault that CUDA is really good. It is however, AMD's, Intel's, Apple's, Qualcomm, ARM's... fault that everything else _sucks hard_. Being angry at nvidia for delivering good products is just stupid. Its the other companies fault that they can't seem to be able to get their sh* together when it comes to GPU computing.
    - 6y ago