4 ms·

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
        Another example of Khronos being stuck with C mindset and poor tooling. Vulkan Compute so far hasn't gotten anywhere.
    - fluffything 6y ago
      > because Nvidia intentionally limits their GPUs to an older OpenCL version that has an uncompetitive featureset So I suppose you still used OpenCL for AMD and Intel hardware because that worked well there? That is, OpenCL only worked poorly on nvidia hardware? If that's the case, I wonder what's your take on OpenCL 3.0 reverting all OpenCL > 1.2 features, such that OpenCL 3 is essentially OpenCL 1.2. The reason given by Khronos is that _nobody_ was implementing these features anyways. Yet your story sounds like AMD had great support for OpenCL newer features, and only nvidia's support was poor, kind of contradicting Khronos themselves. Maybe you meant that nvidia has poor support for OpenCL 1 ?
      - hobofan 6y ago
        Not sure if I can offer a good take, as I don't 100% remember. We didn't have much resources to tackle OpenCL, as it was already hard enough to compete against the other frameworks on the CUDA side alone, so that's where our focus was until our company shut down. IIRC we had all the basics working with OpenCL 1.2 (with an Intel CPU and Titan X as test devices) and were looking into transitioning towards 2.0, as the abstractions used there were much closer to those in CUDA. I remember particularly the memory management in 1.2 to be a pain and difficulties around async RAM<->VRAM copies and subsequent async kernel execution. The latter in particular accounted for the biggest performance differences when profiling the same tasks on the Nvidia GPU. I'm not really informed about what happened with OpenCL 3.0, but I would count any 2.x features as essential when trying to compete with modern CUDA. I don't think the support for OpenCL _the standard_ was bad, but there wasn't really any comparable tooling for OpenCL, and a set of good cuBLAS, cuDNN, etc. alternatives was missing. If OpenCL 3 is really reverting back to 1.2, that sounds like a big mistake.
- 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.

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
      Another example of Khronos being stuck with C mindset and poor tooling. Vulkan Compute so far hasn't gotten anywhere.
  - fluffything 6y ago
    > because Nvidia intentionally limits their GPUs to an older OpenCL version that has an uncompetitive featureset So I suppose you still used OpenCL for AMD and Intel hardware because that worked well there? That is, OpenCL only worked poorly on nvidia hardware? If that's the case, I wonder what's your take on OpenCL 3.0 reverting all OpenCL > 1.2 features, such that OpenCL 3 is essentially OpenCL 1.2. The reason given by Khronos is that _nobody_ was implementing these features anyways. Yet your story sounds like AMD had great support for OpenCL newer features, and only nvidia's support was poor, kind of contradicting Khronos themselves. Maybe you meant that nvidia has poor support for OpenCL 1 ?
    - hobofan 6y ago
      Not sure if I can offer a good take, as I don't 100% remember. We didn't have much resources to tackle OpenCL, as it was already hard enough to compete against the other frameworks on the CUDA side alone, so that's where our focus was until our company shut down. IIRC we had all the basics working with OpenCL 1.2 (with an Intel CPU and Titan X as test devices) and were looking into transitioning towards 2.0, as the abstractions used there were much closer to those in CUDA. I remember particularly the memory management in 1.2 to be a pain and difficulties around async RAM<->VRAM copies and subsequent async kernel execution. The latter in particular accounted for the biggest performance differences when profiling the same tasks on the Nvidia GPU. I'm not really informed about what happened with OpenCL 3.0, but I would count any 2.x features as essential when trying to compete with modern CUDA. I don't think the support for OpenCL _the standard_ was bad, but there wasn't really any comparable tooling for OpenCL, and a set of good cuBLAS, cuDNN, etc. alternatives was missing. If OpenCL 3 is really reverting back to 1.2, that sounds like a big mistake.
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.