6 ms·

I'm not sure I agree with this. In my view the good alternative would have been OpenCL based machine learning libraries, no? Nvidia deliberately undermined tha

I'm not sure I agree with this. In my view the good alternative would have been OpenCL based machine learning libraries, no? Nvidia deliberately undermined that at every turn, and pushed a proprietary solution, hard. Almost all gpgpu based machine learning used it, and, what is AMD left with? HIP, the "CUDA wrapper to make it work on ROCm". What's the alternative here? Say that Nvidia shouldn't do anticompetitive things? That's been an exceedingly successful market strategy for them for quite some time.

pjmlp 4y ago
Don't blame NVidia for Intel and AMD's failure to do anything meaningful with OpenCL, or Google for completely ignoring it on Android and push Renderscript instead.
- okamiueru 4y ago
  What on earth is your point? Let me make one thing clear, I could not care one bit about this team based mentality. Companies can be bad at each their thing. NVIDIA delayed driver support for OpenCL deliberately, because they wanted the only viable alternative for their users to be CUDA. Pushing ML universities to invest resources into that. Your point about AMD nok making something out of OpenCL isn't particularly fair... Maybe what you mean is that they should sponsor their own HPC labs at various universities? Is that "making something out of it"?
  - nightski 4y ago
    What's the advantage of OpenCL if it still only works good on Nvidia? Because it has "Open" in the name? You are acting like it was Nvidia holding OpenCL back, but I'm not convinced that was the case.
  - onphonenow 4y ago
    Nvidia delivered a good solution with cuda. You are whining about them not investing as hard in opencl. What if focusing on cuda was what they thought would let them deliver a good result for users? Lack of focus and sustained investment is part of issue w amd and others. If openCL is the hot thing that nvidia supposedly purposely delaying was a great opportunity for amd and intel to eat their lunch. Where were they?
    - okamiueru 4y ago
      I stopped believing in the well-intentions of NVIDIA a long time ago. Mind you, I didn't stop buying their products. But, they repeat the same shitty stuff all the time. I get why they do it, I get why it works, it's just annoying that people defend it as if it is altruistically motivated (not accusing you of this in particular, but in general). And, as I said, AMD didn't, and still doesn't do a great job in the compute department. And, NVIDIA spent a lot of money developing good solutions with CUDA, their proprietary technology, cannot be anything but a good thing, right? Invest money to "help" universities. Lock core software to your proprietary solutions. Jack up prices. If they only did it in this instance, I'd perhaps give them the benefit of the doubt. But, off the top of my head: - cuda - phys-x - gsync - Gameworks in general - rtx - dlss There is really nothing uniquely special about any of these technologies, other than being (mostly) software solutions tied to NVIDIa hardware, and being pushed heavily onto both developers and researchers. It's the same playbook as "give MatLab/<Any AutoDesk Product> for free to students". These good deeds are not altruistic, they are investments in market capture.
      - deleted 4y ago
        [deleted]
      - pjmlp 4y ago
        Why haven't Intel and AMD did that then?
        okamiueru 4y ago
        One player playing dirty does not imply the rest are saints?
  - pjmlp 4y ago
    My point is exactly that, Intel, AMD and Google are the ones to blame for OpenCL failure, not NVIDIA. And lets not forget that OpenCL came from Apple, which they gave up after messing with Khronos politics. Which is basically the reason Metal came to be, before Khronos decided what OpenGL vNext was supposed to be. Had it not been for AMD's Mantle, they would probably still wondering about it. They were the ones that failed to provide tooling and libraries that would create a valuable ecosystem around OpenCL. It is more than fair, it is always easy to blame others for our failures.
  - bitL 4y ago
    Nvidia took a risk and invented the whole "AI on GPU" industry. AMD and Intel ignored it until they saw big $ there and their strategy was to create an "open system" that would cause external pressure (from folks like you) on Nvidia to share the industry with them. Now, Nvidia's OpenCL performance is better than AMD's but strictly inferior to CUDA, so what are you going to do when AMD fails even in that?
    - okamiueru 4y ago
      NVIDIA did absolutely not "invent AI on GPU", that's a ridiculous statement. When programmable shaders became commonplace, shaders were used to do general computation. That was the birth of GPGPU. NVIDIA jumped on this and developed a lot of very good tooling around that. known as CUDA. Then they invested a lot to make that tooling standard in research departments. Once GPGPU got more commonplace, researchers also doing AI, finding suitable GPGPU tasks, used the more user friendly and advanced tooling, which was CUDA. So, "NVIDIA inventing AI on GPU" suggests you do not know much about the history of AI work on GPUs. But, feel free to correct me.
      - bitL 4y ago
        Nvidia invented HW shaders: https://en.wikipedia.org/wiki/Shader https://en.wikipedia.org/wiki/Shader https://www.khronos.org/opengl/wiki/History_of_Programmability https://www.khronos.org/opengl/wiki/History_of_Programmabili... "The GeForce 3, the first NV20 part, contained the first example of true programmability. Despite NVIDIA being a pioneer of highly configurable fragment processing, its programmability was in its vertex processing. The GeForce 3 was the first GPU that brought programmabilitiy to consumer hardware." The AI on GPGPU was possible only because Nvidia provided a library with matrix and activation functions running on a GPU at speeds far surpassing CPUs and designed a fairly nice API that anybody could understand. There was nothing like that before and that's why they had such a foothold with academic institutions. Of course they didn't invent AI but made it possible to run on their GPUs and actively helped researchers to do that while Intel and AMD slept (well, Intel at least tried to do that on CPU with MKL).
        4y ago
  - incrudible 4y ago
    NVIDIA was not holding back OpenCL. Sure, it supported a lower version, but it actually worked. AMD delivered something that was nominally better and factually broken, time after time after time. Intels implementation was somewhat better, but the hardware was not interesting.
  - dotnet00 4y ago
    The thing about the OpenCL support story is that if you look at version support, it's obvious NVIDIA wasn't at fault. Even despite NVIDIA not being particularly interested in strongly supporting it, Intel, AMD and Qualcomm kept up support for it up to OpenCL 2.0. Get to 2.1 and the only vendor bothering to support it is Intel. OpenCL 2.2 is still only available in ROCm and even that came an entire 4 years after the spec was finalized. It's clear that none of the companies were particularly interested in pushing OpenCL with the effort required for its single source features in 2.0 onwards. Then we get to OpenCL 3.0, where Khronos rolled back most of the big mandatory features from 2.2 and suddenly it's once again supported by NVIDIA, Intel and Samsung mere months after the spec is ratified (AMD noticeably still missing 2+ years later).
ggreg84 4y ago
> OpenCL based machine learning libraries, no? Have you used OpenCL and CUDA C++ ? CUDA C++ is single-source easy to use, has good tools, has a lots of libraries you can build your new library on top (empowered by generic libraries, it can use all pre-existing C++ libraries), ... OpenCL... is not single-source, not easy to use, does not have good tools, does not have good libraries that you can reuse (does not have generics), ... AI is like a F1 race, you can either go race with a F1 car (CUDA C++), or don't go at all. Trying to go with the horsecar OpenCL is, is a waste of time and money. Every other AI startup is going to loop you a million times. > Nvidia deliberately undermined that at every turn, and pushed a proprietary solution, hard. Undermined who at what? Nobody was interested in OpenCL succeeding: not Intel, not AMD, not Apple. All these companies pushed and continue to push for their own proprietary incompatible ecosystems to try to create a platform like NVIDIA has with CUDA. Intel pushes for OneAPI which is Intel only, AMD pushes for their CUDA clone, and Apple pushes for Metal. Its easy to create a new standard. You and me can get together, write something on a napkin, call it a standard, and we are done. We could go around telling people that it's going to be "The Future", like it happened with OpenCL, but that doesn't mean anyone will actually ship something that's usable. It is particularly easy to create a Khronos "standard", of which there are 200, and of which _none_ standardizes standard practice: create the standard first, try to see if it solves the problem later. Claiming that you are entitled to NVIDIA implementing them all, is... well... just that... pure entitlement. From all vendors, ironically, it actually seems that the only vendor working on a portable way to program GPUs is NVIDIA itself, since they have sent a bunch of people regularly to the ISO Fortran and ISO C++ standard committees to extend these languages to allow portable code to run on GPUs without changes. In contrast to OpenCL, ISO Fortran and ISO C++ are actual international standards. I think Fortran supports this since 2018 standard, and C++ since 2017. Ironically, NVIDIA is the only vendor that actually ships this and has for years. The NVIDIA fortran and c++ compilers can run these languages on their GPUs. Intel and AMD will talk about how "portable and cross-vendor" OneAPI and ROCm are, yet their Fortran and C++ implementations still, 5 years later, can't actually use their GPUs. The reason is simple, AMD and Intel don't care / believe / want a portable programming model for GPUs. They want their own closed platform. Unfortunately, since they are at a disadvantage, they need their closed platforms to be able to run on NVIDIA GPUs because otherwise nobody would use them, but that doesn't mean that their platforms are portable or open, and they don't care about code using their platform being able to run well on NVIDIA GPUs since that would be counter productive. So in practice, people still need to use CUDA C++ to target NVIDIA GPUs. Anyways, OpenCL didn't failed "because of NVIDIA". It failed because it is a bad standard, it was a bad standard when it was created (it was significantly worse than the standard practice back then, hence why nobody wanted to use it in practice), and it turns out no vendor is actually interested in it, so it is a worthless standard.
Asooka 4y ago
In my experience, nVidia had the best OpenCL stack of everyone. AMD should probably focus on CUDA support - everyone writes for it and it is a much nicer API. Nothing in it ties it to nVidia hardware. With enough push it will probably get opened like SGI's GL became OpenGL. But at this point I wouldn't trust AMD's graphics division to be able to write a competent driver for anything or to not just abandon their efforts a couple of years in. As for OpenCL, Apple are the ones who killed it in the end to focus on Metal.
- pjmlp 4y ago
  Apple gave OpenCL version 1.0 to Khronos, while they could have helped, it is not their fault that Google (on Android), Intel and AMD couldn't be bothered to actually make something out of it that could compete with tooling, libraries and polyglot infrastructure from CUDA.
dotnet00 4y ago
That is a good question, but unfortunately OpenCL was also a total non-starter for my case. We were adding GPU support to an existing large scientific compute application and wanted to minimize code duplication between CPU and GPU (so single source solutions like CUDA were far more convenient). Additionally, while most users are on Linux, where the OpenCL implementations are fairly reliable, we also needed to support Windows. Unfortunately on Windows AMD's OpenCL implementation is also terrible. It is extremely buggy and the tooling is outdated. I'd spent so many frustrated hours debugging OpenCL back when I was an AMD shill, only to eventually discover that the runtime was bugging out. Occasionally it would even turn out that the bug had been reported on AMD's dev forums years ago without so much as a response. I think that to an extent NVIDIA's lead is well earned. The CUDA ecosystem has been very comfortable to work in, the support tools have been amazingly polished compared to what I had been used to when trying to stick to "open" things like OpenCL. That said, I think that Intel is likely to finally reasonably compete with NVIDIA. While their hardware still has a ways to go, they seem to be putting a large amount of effort into catching up on the software front.

pjmlp 4y ago

Don't blame NVidia for Intel and AMD's failure to do anything meaningful with OpenCL, or Google for completely ignoring it on Android and push Renderscript instead.

okamiueru 4y ago
What on earth is your point? Let me make one thing clear, I could not care one bit about this team based mentality. Companies can be bad at each their thing. NVIDIA delayed driver support for OpenCL deliberately, because they wanted the only viable alternative for their users to be CUDA. Pushing ML universities to invest resources into that. Your point about AMD nok making something out of OpenCL isn't particularly fair... Maybe what you mean is that they should sponsor their own HPC labs at various universities? Is that "making something out of it"?
- nightski 4y ago
  What's the advantage of OpenCL if it still only works good on Nvidia? Because it has "Open" in the name? You are acting like it was Nvidia holding OpenCL back, but I'm not convinced that was the case.
- onphonenow 4y ago
  Nvidia delivered a good solution with cuda. You are whining about them not investing as hard in opencl. What if focusing on cuda was what they thought would let them deliver a good result for users? Lack of focus and sustained investment is part of issue w amd and others. If openCL is the hot thing that nvidia supposedly purposely delaying was a great opportunity for amd and intel to eat their lunch. Where were they?
  - okamiueru 4y ago
    I stopped believing in the well-intentions of NVIDIA a long time ago. Mind you, I didn't stop buying their products. But, they repeat the same shitty stuff all the time. I get why they do it, I get why it works, it's just annoying that people defend it as if it is altruistically motivated (not accusing you of this in particular, but in general). And, as I said, AMD didn't, and still doesn't do a great job in the compute department. And, NVIDIA spent a lot of money developing good solutions with CUDA, their proprietary technology, cannot be anything but a good thing, right? Invest money to "help" universities. Lock core software to your proprietary solutions. Jack up prices. If they only did it in this instance, I'd perhaps give them the benefit of the doubt. But, off the top of my head: - cuda - phys-x - gsync - Gameworks in general - rtx - dlss There is really nothing uniquely special about any of these technologies, other than being (mostly) software solutions tied to NVIDIa hardware, and being pushed heavily onto both developers and researchers. It's the same playbook as "give MatLab/<Any AutoDesk Product> for free to students". These good deeds are not altruistic, they are investments in market capture.
    - deleted 4y ago
      [deleted]
    - pjmlp 4y ago
      Why haven't Intel and AMD did that then?
      - okamiueru 4y ago
        One player playing dirty does not imply the rest are saints?
- pjmlp 4y ago
  My point is exactly that, Intel, AMD and Google are the ones to blame for OpenCL failure, not NVIDIA. And lets not forget that OpenCL came from Apple, which they gave up after messing with Khronos politics. Which is basically the reason Metal came to be, before Khronos decided what OpenGL vNext was supposed to be. Had it not been for AMD's Mantle, they would probably still wondering about it. They were the ones that failed to provide tooling and libraries that would create a valuable ecosystem around OpenCL. It is more than fair, it is always easy to blame others for our failures.
- bitL 4y ago
  Nvidia took a risk and invented the whole "AI on GPU" industry. AMD and Intel ignored it until they saw big $ there and their strategy was to create an "open system" that would cause external pressure (from folks like you) on Nvidia to share the industry with them. Now, Nvidia's OpenCL performance is better than AMD's but strictly inferior to CUDA, so what are you going to do when AMD fails even in that?
  - okamiueru 4y ago
    NVIDIA did absolutely not "invent AI on GPU", that's a ridiculous statement. When programmable shaders became commonplace, shaders were used to do general computation. That was the birth of GPGPU. NVIDIA jumped on this and developed a lot of very good tooling around that. known as CUDA. Then they invested a lot to make that tooling standard in research departments. Once GPGPU got more commonplace, researchers also doing AI, finding suitable GPGPU tasks, used the more user friendly and advanced tooling, which was CUDA. So, "NVIDIA inventing AI on GPU" suggests you do not know much about the history of AI work on GPUs. But, feel free to correct me.
    - bitL 4y ago
      Nvidia invented HW shaders: https://en.wikipedia.org/wiki/Shader https://en.wikipedia.org/wiki/Shader https://www.khronos.org/opengl/wiki/History_of_Programmability https://www.khronos.org/opengl/wiki/History_of_Programmabili... "The GeForce 3, the first NV20 part, contained the first example of true programmability. Despite NVIDIA being a pioneer of highly configurable fragment processing, its programmability was in its vertex processing. The GeForce 3 was the first GPU that brought programmabilitiy to consumer hardware." The AI on GPGPU was possible only because Nvidia provided a library with matrix and activation functions running on a GPU at speeds far surpassing CPUs and designed a fairly nice API that anybody could understand. There was nothing like that before and that's why they had such a foothold with academic institutions. Of course they didn't invent AI but made it possible to run on their GPUs and actively helped researchers to do that while Intel and AMD slept (well, Intel at least tried to do that on CPU with MKL).
      - 4y ago
- incrudible 4y ago
  NVIDIA was not holding back OpenCL. Sure, it supported a lower version, but it actually worked. AMD delivered something that was nominally better and factually broken, time after time after time. Intels implementation was somewhat better, but the hardware was not interesting.
- dotnet00 4y ago
  The thing about the OpenCL support story is that if you look at version support, it's obvious NVIDIA wasn't at fault. Even despite NVIDIA not being particularly interested in strongly supporting it, Intel, AMD and Qualcomm kept up support for it up to OpenCL 2.0. Get to 2.1 and the only vendor bothering to support it is Intel. OpenCL 2.2 is still only available in ROCm and even that came an entire 4 years after the spec was finalized. It's clear that none of the companies were particularly interested in pushing OpenCL with the effort required for its single source features in 2.0 onwards. Then we get to OpenCL 3.0, where Khronos rolled back most of the big mandatory features from 2.2 and suddenly it's once again supported by NVIDIA, Intel and Samsung mere months after the spec is ratified (AMD noticeably still missing 2+ years later).

ggreg84 4y ago

> OpenCL based machine learning libraries, no? Have you used OpenCL and CUDA C++ ? CUDA C++ is single-source easy to use, has good tools, has a lots of libraries you can build your new library on top (empowered by generic libraries, it can use all pre-existing C++ libraries), ... OpenCL... is not single-source, not easy to use, does not have good tools, does not have good libraries that you can reuse (does not have generics), ... AI is like a F1 race, you can either go race with a F1 car (CUDA C++), or don't go at all. Trying to go with the horsecar OpenCL is, is a waste of time and money. Every other AI startup is going to loop you a million times. > Nvidia deliberately undermined that at every turn, and pushed a proprietary solution, hard. Undermined who at what? Nobody was interested in OpenCL succeeding: not Intel, not AMD, not Apple. All these companies pushed and continue to push for their own proprietary incompatible ecosystems to try to create a platform like NVIDIA has with CUDA. Intel pushes for OneAPI which is Intel only, AMD pushes for their CUDA clone, and Apple pushes for Metal. Its easy to create a new standard. You and me can get together, write something on a napkin, call it a standard, and we are done. We could go around telling people that it's going to be "The Future", like it happened with OpenCL, but that doesn't mean anyone will actually ship something that's usable. It is particularly easy to create a Khronos "standard", of which there are 200, and of which _none_ standardizes standard practice: create the standard first, try to see if it solves the problem later. Claiming that you are entitled to NVIDIA implementing them all, is... well... just that... pure entitlement. From all vendors, ironically, it actually seems that the only vendor working on a portable way to program GPUs is NVIDIA itself, since they have sent a bunch of people regularly to the ISO Fortran and ISO C++ standard committees to extend these languages to allow portable code to run on GPUs without changes. In contrast to OpenCL, ISO Fortran and ISO C++ are actual international standards. I think Fortran supports this since 2018 standard, and C++ since 2017. Ironically, NVIDIA is the only vendor that actually ships this and has for years. The NVIDIA fortran and c++ compilers can run these languages on their GPUs. Intel and AMD will talk about how "portable and cross-vendor" OneAPI and ROCm are, yet their Fortran and C++ implementations still, 5 years later, can't actually use their GPUs. The reason is simple, AMD and Intel don't care / believe / want a portable programming model for GPUs. They want their own closed platform. Unfortunately, since they are at a disadvantage, they need their closed platforms to be able to run on NVIDIA GPUs because otherwise nobody would use them, but that doesn't mean that their platforms are portable or open, and they don't care about code using their platform being able to run well on NVIDIA GPUs since that would be counter productive. So in practice, people still need to use CUDA C++ to target NVIDIA GPUs. Anyways, OpenCL didn't failed "because of NVIDIA". It failed because it is a bad standard, it was a bad standard when it was created (it was significantly worse than the standard practice back then, hence why nobody wanted to use it in practice), and it turns out no vendor is actually interested in it, so it is a worthless standard.

Asooka 4y ago

In my experience, nVidia had the best OpenCL stack of everyone. AMD should probably focus on CUDA support - everyone writes for it and it is a much nicer API. Nothing in it ties it to nVidia hardware. With enough push it will probably get opened like SGI's GL became OpenGL. But at this point I wouldn't trust AMD's graphics division to be able to write a competent driver for anything or to not just abandon their efforts a couple of years in. As for OpenCL, Apple are the ones who killed it in the end to focus on Metal.

pjmlp 4y ago
Apple gave OpenCL version 1.0 to Khronos, while they could have helped, it is not their fault that Google (on Android), Intel and AMD couldn't be bothered to actually make something out of it that could compete with tooling, libraries and polyglot infrastructure from CUDA.

dotnet00 4y ago

That is a good question, but unfortunately OpenCL was also a total non-starter for my case. We were adding GPU support to an existing large scientific compute application and wanted to minimize code duplication between CPU and GPU (so single source solutions like CUDA were far more convenient). Additionally, while most users are on Linux, where the OpenCL implementations are fairly reliable, we also needed to support Windows. Unfortunately on Windows AMD's OpenCL implementation is also terrible. It is extremely buggy and the tooling is outdated. I'd spent so many frustrated hours debugging OpenCL back when I was an AMD shill, only to eventually discover that the runtime was bugging out. Occasionally it would even turn out that the bug had been reported on AMD's dev forums years ago without so much as a response. I think that to an extent NVIDIA's lead is well earned. The CUDA ecosystem has been very comfortable to work in, the support tools have been amazingly polished compared to what I had been used to when trying to stick to "open" things like OpenCL. That said, I think that Intel is likely to finally reasonably compete with NVIDIA. While their hardware still has a ways to go, they seem to be putting a large amount of effort into catching up on the software front.