6 ms·

> AMD could release a 2x powerful GPGPU tomorrow for half the price and most current NVIDIA users wouldn't care because what good is that if you can't program i

by adev_ 6y ago

> AMD could release a 2x powerful GPGPU tomorrow for half the price and most current NVIDIA users wouldn't care because what good is that if you can't program it?. Correction: Nobody will be able to use the AMD hardware (outside of computer graphics) because everybody has been locked-in with CUDA on Nvidia. They can not even change even if they want to: it is pure madness to reprogram an entire GPGPU software stack every 2 years just to change your hardware provider. And I think it will remain like that until NVidia get sued for anti-trust. > ARM and Intel make great software [..] doesn't open-source any of that either for the same reasons as NVIDIA. That's propaganda and it's wrong. Intel and ARM contribute a lot to OSS. Most of the software they release nowadays is Open Source. This includes compiler support, drivers, libraries and entire dev environment: mkl-dnn, TBB, BLIS, ISPC, "One", mbedTLS.... ARM has even an entire foundation only to contribute to OSS (https://www.linaro.org/ https://www.linaro.org/) . Near to that, NVidia does close to nothing. There is no justification to NVidia's attitude related to OSS. It reminds me the one of Microsoft at its darkest days. The only excuse I can see to this attitude is greed. I hope at least they do not contaminate Mellanox with their toxic policies. Mellanox was an example of successful Open Source contributor/company (up to now) with OFabric (https://www.openfabrics.org/ https://www.openfabrics.org/). It would be dramatic if this disappear.

fluffything 6y ago
> Correction: Nobody will be able to use the AMD hardware (outside of computer graphics) because everybody has been locked-in with CUDA on Nvidia. NVIDA open-sourced their CUDA implementation to the LLVM project 5 years ago, which is why clang can compile CUDA today, and why Intel and PGI have clang forks compiling CUDA to multi-threaded and vectorized x86-64 using OpenMP. That you can't compile CUDA to AMD GPUs isn't NVIDIA's fault, it's AMD, for deciding to pursue OpenCL first, then HSA, and now HIP.
- adev_ 6y ago
  > Do you work for AMD I do not. And I use NVidia hardware regularly for GPGPU. But I hate fanboyism. > NVIDA open-source their CUDA implementation to the LLVM project 5 years ago Correction: Google developped an internal CUDA implementation for their own need based on LLVM that Nvidia barely supported it for their own need afterwards. Nothing is "stable" nor "branded" in this work.... Consequently, 99% of public Open Source CUDA-using software still compile ONLY with the CUDA proprietary toolchain ONLY on NVidia hardware. And this is not going to change anything soon. > one from PGI, that compile CUDA to multi-threaded x86-64 code using OpenMP. The PGI compiler is proprietary and now property of NVidia. It was previously properitary and independant but mainly used for its GPGPU capability through OpenACC. OpenACC backend targets directly the nvidiaptx (proprietary) format. Nothing related with CUDA. > Intel being the main vendor pushing for a parallel STL in the C++ standard That's wrong again. Most of the work done for the parallel STL and by the C++ committee originate from work from HPX and the STELLAR Group (http://stellar-group.org/libraries/hpx/ http://stellar-group.org/libraries/hpx/). They are pretty smart people and deserve at least respect and parent-ship for what they have done. More information from Hermut Kaiser (Very Nice Guy btw) here (https://www.youtube.com/watch?v=6Z3_qaFYF84 https://www.youtube.com/watch?v=6Z3_qaFYF84). They have been the precursor of the idea of parallel "algorithms" in the STL and the concept of "Execution policy" you have in C++17 comes from them. To the defense of Intel (and up to my knowledge) they have provided the first OSS implementation for compilers for it.
  - adev_ 6y ago
    > That you can't compile CUDA to AMD GPUs isn't NVIDIA's fault, it's AMD, for deciding to pursue OpenCL first, then HSA, and now HIP. Using a branded & under patent concurrent proprietary technology and copying its API for your own implementation is Maddness that will lead you for sure in front of a court. It seems that even Google understood that the hard way (https://en.wikipedia.org/wiki/Google_v._Oracle_America https://en.wikipedia.org/wiki/Google_v._Oracle_America)
    - monocasa 6y ago
      Google v Oracle is still unsettled. Most other legal precedent was that it was fine to clone an API.
      - adev_ 6y ago
        > Most other legal precedent was that it was fine to clone an API. CUDA is more than an API. It is a technology under copyright and very likely patented too. Even the API itself contains multiple reference to "CUDA" in function calls and variable name.
        monocasa 6y ago
        None of that protects it from being cloned under previous 9th circuit precedent except maybe patents, but I'm not aware of any patents that'd protect another against CUDA implementation.
    - fluffything 6y ago
      How come? There is a CUDA C++ and CUDA C toolchains available under a MIT license, large part s of which are contributed by NVIDIA. How can they sue you for using something that they give you with a license that says "we allow you to do whatever you want with it" ?
      - Teknoman117 6y ago
        the MIT license doesn't have an express patent grant. If Nvidia has a patent on some technology used by the open source code, they could sue you for patent infringement if you use it in a way that displeases them. What they can't do is sue you for copyright infringement.
- mambru 6y ago
  >Intel and PGI have clang forks compiling CUDA to multi-threaded and vectorized x86-64 using OpenMP. Where are these forks?
  - pjmlp 6y ago
    For Intel, https://software.intel.com/content/www/us/en/develop/tools/oneapi.html https://software.intel.com/content/www/us/en/develop/tools/o...
  - fluffything 6y ago
    For PGI, all pgi compilers can do this, just pick x86-64 as the target. There are also other forks online (just search for LLVM, CUDA, x86 as keywords), some university groups have their forks on github, where they compile CUDA to x.
amelius 6y ago
> Nobody will be able to use the AMD hardware (outside of computer graphics) because everybody has been locked-in with CUDA on Nvidia. But numpy can be ported. So can pytorch. I don't think the lock-in is that big of an issue. GPUs do only simple things, but do them fast.
- adev_ 6y ago
  > But numpy can be ported. So can pytorch. Letting AMD or Intel port themselves everything that has been developed in CUDA like it was done for Pytorch is not substainable and will always lag behind. It can only help to create a monopoly on the long term.
  - slavik81 6y ago
    As Hip continues to implement more of CUDA, I think we'll see more developers doing it themselves when the barrier to porting is smaller. AMD has a lot of work to do, and I don't know whether they'll succeed or not, but IMO they have the right strategy.
- david-gpu 6y ago
  > GPUs do only simple things, but do them fast GPUs are immensely complex systems. Look at an API like Vulcan, plus it's shading language, and tell me again it's simple. And that's a low-level interface. Now add to that the enormous amount of software effort that goes into implementing efficient libraries like cuBLAS, cuDNN, etc. There's a reason other vendors have struggled to compete with NVidia. Disclaimer: currently employed at NVidia.
- lumost 6y ago
  Part of Nvidia's advantage comes from building the hardware and software side by side. No one was seriously tackling GPGPU until Nvidia created Cuda, and if you look at the rest of the graphics stack Nvidia is the one driving the big innovations. GPUs are sufficiently specialized in both interface and problem domain that GPU enhanced software is unlikely to appear without a large vendor driving development, and it would be tough for that vendor to fund application development if there is no lock in on the chips. which leads to the real question. What business model would enable GPU/AI software development without hardware lock-in? Game development has found a viable business by charging game publishers.
gnufx 6y ago
Intel don't release BLIS, though there is some Intel contribution. Substitute libxsmm, which originally beat MKL.
Polylactic_acid 6y ago
Amd doesn't even have software for GPGPU on some of their cards. I have an rx5700xt and I cant use it for anything but gaming because ROCm doesn't support navi cards, a whole year after its release.
- csdreamer7 6y ago
  As a 5700 owner, I agree. It gets even worse. There was recently a regression in the 5.4, 5.5, and 5.6 kernels that hit me hard for a week or so on Manjaro last month. System just decided to lock up or restart. Thought the graphics card had died when it happened once on Windows. Working fine now-these drivers have been out for 10 months now. Even worse, AMD has locked down the releases of some of their 'GPUOpen' software. https://www.phoronix.com/scan.php?page=news_item&px=Radeon-Rays-4.0-Released https://www.phoronix.com/scan.php?page=news_item&px=Radeon-R... https://www.phoronix.com/scan.php?page=news_item&px=GPUOpen-RMV-Binary-Release https://www.phoronix.com/scan.php?page=news_item&px=GPUOpen-... I did not expect the second one to be open source; just not on their GPUOpen website. I did expect the first one to 'stay' open source. Not to be made proprietary on their 'GPUOpen' website. I am definitely keeping an eye on Intel graphics now.
- ksec 6y ago
  I think at this point AMD wants anything Compute to concentrate on CDNA, and graphics remain on RDNA.
BeetleB 6y ago
>> ARM and Intel make great software [..] doesn't open-source any of that either for the same reasons as NVIDIA. > That's propaganda and it's wrong. Very convenient of you to have omitted what was in the square brackets: > Intel MKL, Intel SVML, ... libraries, icc, ifort, ... compiler Show me the open source MKL, Intel SVML, icc and ifort. Some (all?) of it may be free, but it's not open source.
- rodburns 6y ago
  I don't necessarily have an opinion either way in this discussion but wanted to point out that Intel's latest MKL library does seem to be done as an open source project https://github.com/oneapi-src/oneMKL https://github.com/oneapi-src/oneMKL

by adev_ 6y ago

fluffything 6y ago

> Correction: Nobody will be able to use the AMD hardware (outside of computer graphics) because everybody has been locked-in with CUDA on Nvidia. NVIDA open-sourced their CUDA implementation to the LLVM project 5 years ago, which is why clang can compile CUDA today, and why Intel and PGI have clang forks compiling CUDA to multi-threaded and vectorized x86-64 using OpenMP. That you can't compile CUDA to AMD GPUs isn't NVIDIA's fault, it's AMD, for deciding to pursue OpenCL first, then HSA, and now HIP.

adev_ 6y ago
> Do you work for AMD I do not. And I use NVidia hardware regularly for GPGPU. But I hate fanboyism. > NVIDA open-source their CUDA implementation to the LLVM project 5 years ago Correction: Google developped an internal CUDA implementation for their own need based on LLVM that Nvidia barely supported it for their own need afterwards. Nothing is "stable" nor "branded" in this work.... Consequently, 99% of public Open Source CUDA-using software still compile ONLY with the CUDA proprietary toolchain ONLY on NVidia hardware. And this is not going to change anything soon. > one from PGI, that compile CUDA to multi-threaded x86-64 code using OpenMP. The PGI compiler is proprietary and now property of NVidia. It was previously properitary and independant but mainly used for its GPGPU capability through OpenACC. OpenACC backend targets directly the nvidiaptx (proprietary) format. Nothing related with CUDA. > Intel being the main vendor pushing for a parallel STL in the C++ standard That's wrong again. Most of the work done for the parallel STL and by the C++ committee originate from work from HPX and the STELLAR Group (http://stellar-group.org/libraries/hpx/ http://stellar-group.org/libraries/hpx/). They are pretty smart people and deserve at least respect and parent-ship for what they have done. More information from Hermut Kaiser (Very Nice Guy btw) here (https://www.youtube.com/watch?v=6Z3_qaFYF84 https://www.youtube.com/watch?v=6Z3_qaFYF84). They have been the precursor of the idea of parallel "algorithms" in the STL and the concept of "Execution policy" you have in C++17 comes from them. To the defense of Intel (and up to my knowledge) they have provided the first OSS implementation for compilers for it.
- adev_ 6y ago
  > That you can't compile CUDA to AMD GPUs isn't NVIDIA's fault, it's AMD, for deciding to pursue OpenCL first, then HSA, and now HIP. Using a branded & under patent concurrent proprietary technology and copying its API for your own implementation is Maddness that will lead you for sure in front of a court. It seems that even Google understood that the hard way (https://en.wikipedia.org/wiki/Google_v._Oracle_America https://en.wikipedia.org/wiki/Google_v._Oracle_America)
  - monocasa 6y ago
    Google v Oracle is still unsettled. Most other legal precedent was that it was fine to clone an API.
    - adev_ 6y ago
      > Most other legal precedent was that it was fine to clone an API. CUDA is more than an API. It is a technology under copyright and very likely patented too. Even the API itself contains multiple reference to "CUDA" in function calls and variable name.
      - monocasa 6y ago
        None of that protects it from being cloned under previous 9th circuit precedent except maybe patents, but I'm not aware of any patents that'd protect another against CUDA implementation.
  - fluffything 6y ago
    How come? There is a CUDA C++ and CUDA C toolchains available under a MIT license, large part s of which are contributed by NVIDIA. How can they sue you for using something that they give you with a license that says "we allow you to do whatever you want with it" ?
    - Teknoman117 6y ago
      the MIT license doesn't have an express patent grant. If Nvidia has a patent on some technology used by the open source code, they could sue you for patent infringement if you use it in a way that displeases them. What they can't do is sue you for copyright infringement.
mambru 6y ago
>Intel and PGI have clang forks compiling CUDA to multi-threaded and vectorized x86-64 using OpenMP. Where are these forks?
- pjmlp 6y ago
  For Intel, https://software.intel.com/content/www/us/en/develop/tools/oneapi.html https://software.intel.com/content/www/us/en/develop/tools/o...
- fluffything 6y ago
  For PGI, all pgi compilers can do this, just pick x86-64 as the target. There are also other forks online (just search for LLVM, CUDA, x86 as keywords), some university groups have their forks on github, where they compile CUDA to x.

amelius 6y ago

> Nobody will be able to use the AMD hardware (outside of computer graphics) because everybody has been locked-in with CUDA on Nvidia. But numpy can be ported. So can pytorch. I don't think the lock-in is that big of an issue. GPUs do only simple things, but do them fast.

adev_ 6y ago
> But numpy can be ported. So can pytorch. Letting AMD or Intel port themselves everything that has been developed in CUDA like it was done for Pytorch is not substainable and will always lag behind. It can only help to create a monopoly on the long term.
- slavik81 6y ago
  As Hip continues to implement more of CUDA, I think we'll see more developers doing it themselves when the barrier to porting is smaller. AMD has a lot of work to do, and I don't know whether they'll succeed or not, but IMO they have the right strategy.
david-gpu 6y ago
> GPUs do only simple things, but do them fast GPUs are immensely complex systems. Look at an API like Vulcan, plus it's shading language, and tell me again it's simple. And that's a low-level interface. Now add to that the enormous amount of software effort that goes into implementing efficient libraries like cuBLAS, cuDNN, etc. There's a reason other vendors have struggled to compete with NVidia. Disclaimer: currently employed at NVidia.
lumost 6y ago
Part of Nvidia's advantage comes from building the hardware and software side by side. No one was seriously tackling GPGPU until Nvidia created Cuda, and if you look at the rest of the graphics stack Nvidia is the one driving the big innovations. GPUs are sufficiently specialized in both interface and problem domain that GPU enhanced software is unlikely to appear without a large vendor driving development, and it would be tough for that vendor to fund application development if there is no lock in on the chips. which leads to the real question. What business model would enable GPU/AI software development without hardware lock-in? Game development has found a viable business by charging game publishers.

gnufx 6y ago

Intel don't release BLIS, though there is some Intel contribution. Substitute libxsmm, which originally beat MKL.

Polylactic_acid 6y ago

Amd doesn't even have software for GPGPU on some of their cards. I have an rx5700xt and I cant use it for anything but gaming because ROCm doesn't support navi cards, a whole year after its release.

csdreamer7 6y ago
As a 5700 owner, I agree. It gets even worse. There was recently a regression in the 5.4, 5.5, and 5.6 kernels that hit me hard for a week or so on Manjaro last month. System just decided to lock up or restart. Thought the graphics card had died when it happened once on Windows. Working fine now-these drivers have been out for 10 months now. Even worse, AMD has locked down the releases of some of their 'GPUOpen' software. https://www.phoronix.com/scan.php?page=news_item&px=Radeon-Rays-4.0-Released https://www.phoronix.com/scan.php?page=news_item&px=Radeon-R... https://www.phoronix.com/scan.php?page=news_item&px=GPUOpen-RMV-Binary-Release https://www.phoronix.com/scan.php?page=news_item&px=GPUOpen-... I did not expect the second one to be open source; just not on their GPUOpen website. I did expect the first one to 'stay' open source. Not to be made proprietary on their 'GPUOpen' website. I am definitely keeping an eye on Intel graphics now.
ksec 6y ago
I think at this point AMD wants anything Compute to concentrate on CDNA, and graphics remain on RDNA.

BeetleB 6y ago

>> ARM and Intel make great software [..] doesn't open-source any of that either for the same reasons as NVIDIA. > That's propaganda and it's wrong. Very convenient of you to have omitted what was in the square brackets: > Intel MKL, Intel SVML, ... libraries, icc, ifort, ... compiler Show me the open source MKL, Intel SVML, icc and ifort. Some (all?) of it may be free, but it's not open source.

rodburns 6y ago
I don't necessarily have an opinion either way in this discussion but wanted to point out that Intel's latest MKL library does seem to be done as an open source project https://github.com/oneapi-src/oneMKL https://github.com/oneapi-src/oneMKL