4 ms·

I'm also curious why AMD hasn't implemented something like CUDA cores for ML. AMD cards are basically useless for doing any intensive ML task.

smoldesu 4y ago
They did try. A few years ago AMD and Apple collaborated to make OpenCL, which was a pretty half-hearted attempt at building a platform-agnostic GPGPU library. Their heart was in the right place, but that was part of the problem. Nvidia's vertical control over their hardware and software stack gave them insane leveraging power for lots of dedicated use cases (video editing, gaming, 3D rendering, machine learning, etc.) In the end, even after years of development, OpenCL was just really slow. There wasn't a whole lot of adoption in the backend market, and Apple was getting ready to kick them to the curb anyways. It's a little bit of a shame that AMD got their teeth kicked in for playing Mr. Nice Guy, but they should have know that Nvidia and Apple race for pinks.
- paulmd 4y ago
  OpenCL had a bit of a "second-mover curse" where instead of trying to solve one problem (GPGPU acceleration) it tried to solve everything (a generalized framework for heterogeneous dispatch) and it just kinda sucks to actually use. It's not that it's slower or faster, in principle it should be the same speed when dispatched to the hardware (+/- any C/C++ optimization gotchas of course), but it just requires an obscene amount of boilerplate to "draw the first triangle" (or, launch the first kernel), much like Vulkan, and their own solution is still a pretty clos HIP was supposed to rectify this, but now you're buying into AMD's custom language and its limitations... and there are limitations, things that CUDA can do that HIP can't (texture unit access was an early one - and texture units aren't just for texturing, they're for coalescing all kinds of 2d/3d/higher-dimensional memory access). And AMD has a history of abandoning these projects after a couple years and leaving them behind and unsupported... like their Thrust framework counterpart, Bolt, which hasn't been updated in 8 years now. https://github.com/HSA-Libraries/Bolt https://github.com/HSA-Libraries/Bolt The old bit about "Vendor B" leaving behind a "trail of projects designed to pad resumes and show progress to middle managers" still reigns absolutely true with AMD. AMD has a big uphill climb in general to shake this reputation about being completely unserious with their software... and I'm not even talking about drivers here. This is even more the widespread community perception with their GPGPU/ML efforts than with their drivers. http://richg42.blogspot.com/2014/05/the-truth-on-opengl-driver-quality.html http://richg42.blogspot.com/2014/05/the-truth-on-opengl-driv... AMD doesn't have a library of warp-level/kernel-level/global "software primitives" like Cuda Unbound or Thrust either. So instead of writing your application, you are writing the primitives library, or writing your own poor implementation of them. https://github.com/NVIDIA/cub https://github.com/NVIDIA/cub https://github.com/NVIDIA/thrust https://github.com/NVIDIA/thrust It's just a fractal problem of "the software doesn't exist and AMD would really rather you write it for them" all the way down and nobody wants to do that instead of doing their own work. AMD is the one who benefits from the rewrite, for everyone else it's a "best case scenario it works the same as what we've already got", so if AMD isn't gonna do it then pretty much nobody else is gonna leap on it. And then AMD has poor adoption and no software and the cycle continues. AMD really really just needs to get serious and hire a half dozen engineers to sit there and write this software, cause it's just not going to happen otherwise. It's a drop in the bucket vs the sales to be realized here even in the medium term, like one big ML sale would probably more than pay those salaries. They're not doing it because they're cheap or they're doing it because they're not really serious, take your pick, but, AMD is no longer that broke, they can afford it and it makes financial sense. Again, not a "nice" thing to say but it's the cold truth here. I feel like I've made some variation on this post about every 6 months for like 5 years now but it's still relevant. If you as a vendor don't care about writing good code for key features/libraries for your product, nobody else is either, and you'll never get uptake. It's the same thing with AMD/ATI not embedding developers with studios to get those optimizations for their architectures. Console lock-in will only get you so far. If you don't care about the product as a vendor, nobody else will either. It's remarkable how much flak Jensen got for "NVIDIA is a software company now" back in 2009, and how people still don't get it, AMD is not a software company and that's why they keep failing. Writing the framework that turns into StableDiffusion and sells a billion dollars of GPUs is the NVIDIA business model, AMD keeps trying to jump straight to the "sell a billion dollars of GPUs" part and keeps failing.
  - slavik81 4y ago
    The ROCm software primatives library is rocPRIM [1] and the ROCm equivalent to Thrust is rocThrust [2]. Though, if you're a user of CUB, it might be easier to use hipCUB [3] to support both platforms. [1]: https://github.com/ROCmSoftwarePlatform/rocPRIM https://github.com/ROCmSoftwarePlatform/rocPRIM [2]: https://github.com/ROCmSoftwarePlatform/rocThrust https://github.com/ROCmSoftwarePlatform/rocThrust [3]: https://github.com/ROCmSoftwarePlatform/hipCUB https://github.com/ROCmSoftwarePlatform/hipCUB
    - paulmd 4y ago
      That's HIP, and you're putting your faith in ongoing support, but, it's cool that those libraries got ported. I bet my old thesis would probably HIPify pretty well.
      - slavik81 4y ago
        I work on the ROCm libraries and I have faith in my ongoing employment. There's still lots of work on our roadmap. I joined AMD because I believed HIP could be successful. I don't plan to leave until either we have made it so or I no longer believe it can be.
- pjmlp 4y ago
  Intel and AMD never bothered to move OpenCL beyond bare bones C source, while NVidia not only moved CUDO into a polyglot ecosystem early on, they doubled down on IDE for GPGPU computing and first class libraries. Google never bothered with OpenCL on Android, pushing their C99 Renderscript dialect instead. Apple repented themselves of offering OpenGL to Khronos and the direction not going into the way they wanted to. Those that blame NVidia for their "practices" should rather look into how bad the competition has been from day one.
paulmd 4y ago
AMD has "tensor cores" (called something different but they're very similar matrix accelerator units) in CDNA. RNDA3 is supposed to have "something", it has the same instruction as CDNA, it's supposed to be less than a full unit but presumably there wouldn't be an instruction without some level of hardware acceleration either. The bigger problem is that AMD doesn't want to pay to keep up on the software side... at the end of the day when you're coming from behind you just have to pay someone to port key pieces of software to your platform. AMD has really coasted for a long time on letting the open-source community do their work for them, but that's not going to fly with things like PyTorch or other key pieces of software... if AMD wants the sales and the adoption of their hardware, it's just going to have to pay someone to write the software, so that people who want to do research and not PyTorch maintenance can justify buying the hardware. I am not particularly interested in the perceived historical justifications for the current situation, it doesn't matter to the businesses who might be AMD's customers. And actually in many ways they've gotten even shakier recently, what with dropping RDNA support from their NN/ML package. As a cold statement of reality, this is table stakes going forward and if AMD doesn't want to do it they won't get the sales. It's not even just PyTorch either, it's... everything. AMD is just coming from a million miles behind on the software, and "welp just write it yourself if you want to use our hardware" is not an attitude that is conductive to selling hardware.
- rektide 4y ago
  Which libraries is AMD dropping RDNA support in? That seems very inadvised. Nvidia's libraries being usable by a broad range of developers on a wide range of hardware is critical to their wide adoption. AMD cannot expect to have real adoption if only their fancy enterprise grade unobtanium cards support ML systems. AMD needs a wide & engaged community trying to yse their stuff to figure out what software/drivers they simply have to build.
  - paulmd 4y ago
    Talking specifically about ROCm here, their ML package. God this is such a tough paragraph to write accurately. AMD themselves have conflicting information all over their docs and repos and half of it is not even marked as "outdated"... https://docs.amd.com/bundle/ROCm-Getting-Started-Guide-v5.2.3 https://docs.amd.com/bundle/ROCm-Getting-Started-Guide-v5.2.... The official supported platforms at this point are RDNA2 (pro), GFX9 (pro), and CDNA. Consumer versions of these (RDNA2, Radeon VII, and Vega 56/64) probably work, although Vega 56/64 are an older version with much less hardware support as well. RDNA2 support is also "partial" and ymmv, things are often broken even on supported cards. If RDNA2 works, then RDNA1 may work, but again, mega ymmv, things may not even be great with RDNA2 yet. The "hardware guide" link talks about supporting Vega 10 (that's V56/64) and says GFX8 (Polaris) and GFX7 (Hawaii) are supported... but that doc is tagged 5.0 and 5.1 was the release that dropped the other stuff. So I'd say Vega 64/56 chips are probably broken at this point, on the current builds. Up until earlier this year though, it was unsupported on any consumer card except Radeon VII. They dropped Hawaii/Polaris/Vega support about 6 months before they started adding partial RDNA2 support back. And in contrast... NVIDIA's shit runs on everything, going back 10 years or more. At least to Kepler, if not Fermi or Tesla uarch (GTX 8800 series). It may not run great, but CUDA is CUDA, feature support has been a nearly forward ratchet, and they've had PTX to provide a rosetta stone in between the various architectural changes. I mean... at the end of the day the hardware hasn't changed that much, surely you can provide a shader fallback (which is required anyway since RDNA2 doesn't have tensor acceleration). I don't get what the deal is tbh. https://www.techpowerup.com/288864/amd-rocm-4-5-drops-polaris-architecture-support https://www.techpowerup.com/288864/amd-rocm-4-5-drops-polari... https://www.phoronix.com/news/Radeon-ROCm-5.1 https://www.phoronix.com/news/Radeon-ROCm-5.1

smoldesu 4y ago

They did try. A few years ago AMD and Apple collaborated to make OpenCL, which was a pretty half-hearted attempt at building a platform-agnostic GPGPU library. Their heart was in the right place, but that was part of the problem. Nvidia's vertical control over their hardware and software stack gave them insane leveraging power for lots of dedicated use cases (video editing, gaming, 3D rendering, machine learning, etc.) In the end, even after years of development, OpenCL was just really slow. There wasn't a whole lot of adoption in the backend market, and Apple was getting ready to kick them to the curb anyways. It's a little bit of a shame that AMD got their teeth kicked in for playing Mr. Nice Guy, but they should have know that Nvidia and Apple race for pinks.

paulmd 4y ago
OpenCL had a bit of a "second-mover curse" where instead of trying to solve one problem (GPGPU acceleration) it tried to solve everything (a generalized framework for heterogeneous dispatch) and it just kinda sucks to actually use. It's not that it's slower or faster, in principle it should be the same speed when dispatched to the hardware (+/- any C/C++ optimization gotchas of course), but it just requires an obscene amount of boilerplate to "draw the first triangle" (or, launch the first kernel), much like Vulkan, and their own solution is still a pretty clos HIP was supposed to rectify this, but now you're buying into AMD's custom language and its limitations... and there are limitations, things that CUDA can do that HIP can't (texture unit access was an early one - and texture units aren't just for texturing, they're for coalescing all kinds of 2d/3d/higher-dimensional memory access). And AMD has a history of abandoning these projects after a couple years and leaving them behind and unsupported... like their Thrust framework counterpart, Bolt, which hasn't been updated in 8 years now. https://github.com/HSA-Libraries/Bolt https://github.com/HSA-Libraries/Bolt The old bit about "Vendor B" leaving behind a "trail of projects designed to pad resumes and show progress to middle managers" still reigns absolutely true with AMD. AMD has a big uphill climb in general to shake this reputation about being completely unserious with their software... and I'm not even talking about drivers here. This is even more the widespread community perception with their GPGPU/ML efforts than with their drivers. http://richg42.blogspot.com/2014/05/the-truth-on-opengl-driver-quality.html http://richg42.blogspot.com/2014/05/the-truth-on-opengl-driv... AMD doesn't have a library of warp-level/kernel-level/global "software primitives" like Cuda Unbound or Thrust either. So instead of writing your application, you are writing the primitives library, or writing your own poor implementation of them. https://github.com/NVIDIA/cub https://github.com/NVIDIA/cub https://github.com/NVIDIA/thrust https://github.com/NVIDIA/thrust It's just a fractal problem of "the software doesn't exist and AMD would really rather you write it for them" all the way down and nobody wants to do that instead of doing their own work. AMD is the one who benefits from the rewrite, for everyone else it's a "best case scenario it works the same as what we've already got", so if AMD isn't gonna do it then pretty much nobody else is gonna leap on it. And then AMD has poor adoption and no software and the cycle continues. AMD really really just needs to get serious and hire a half dozen engineers to sit there and write this software, cause it's just not going to happen otherwise. It's a drop in the bucket vs the sales to be realized here even in the medium term, like one big ML sale would probably more than pay those salaries. They're not doing it because they're cheap or they're doing it because they're not really serious, take your pick, but, AMD is no longer that broke, they can afford it and it makes financial sense. Again, not a "nice" thing to say but it's the cold truth here. I feel like I've made some variation on this post about every 6 months for like 5 years now but it's still relevant. If you as a vendor don't care about writing good code for key features/libraries for your product, nobody else is either, and you'll never get uptake. It's the same thing with AMD/ATI not embedding developers with studios to get those optimizations for their architectures. Console lock-in will only get you so far. If you don't care about the product as a vendor, nobody else will either. It's remarkable how much flak Jensen got for "NVIDIA is a software company now" back in 2009, and how people still don't get it, AMD is not a software company and that's why they keep failing. Writing the framework that turns into StableDiffusion and sells a billion dollars of GPUs is the NVIDIA business model, AMD keeps trying to jump straight to the "sell a billion dollars of GPUs" part and keeps failing.
- slavik81 4y ago
  The ROCm software primatives library is rocPRIM [1] and the ROCm equivalent to Thrust is rocThrust [2]. Though, if you're a user of CUB, it might be easier to use hipCUB [3] to support both platforms. [1]: https://github.com/ROCmSoftwarePlatform/rocPRIM https://github.com/ROCmSoftwarePlatform/rocPRIM [2]: https://github.com/ROCmSoftwarePlatform/rocThrust https://github.com/ROCmSoftwarePlatform/rocThrust [3]: https://github.com/ROCmSoftwarePlatform/hipCUB https://github.com/ROCmSoftwarePlatform/hipCUB
  - paulmd 4y ago
    That's HIP, and you're putting your faith in ongoing support, but, it's cool that those libraries got ported. I bet my old thesis would probably HIPify pretty well.
    - slavik81 4y ago
      I work on the ROCm libraries and I have faith in my ongoing employment. There's still lots of work on our roadmap. I joined AMD because I believed HIP could be successful. I don't plan to leave until either we have made it so or I no longer believe it can be.
pjmlp 4y ago
Intel and AMD never bothered to move OpenCL beyond bare bones C source, while NVidia not only moved CUDO into a polyglot ecosystem early on, they doubled down on IDE for GPGPU computing and first class libraries. Google never bothered with OpenCL on Android, pushing their C99 Renderscript dialect instead. Apple repented themselves of offering OpenGL to Khronos and the direction not going into the way they wanted to. Those that blame NVidia for their "practices" should rather look into how bad the competition has been from day one.

paulmd 4y ago

AMD has "tensor cores" (called something different but they're very similar matrix accelerator units) in CDNA. RNDA3 is supposed to have "something", it has the same instruction as CDNA, it's supposed to be less than a full unit but presumably there wouldn't be an instruction without some level of hardware acceleration either. The bigger problem is that AMD doesn't want to pay to keep up on the software side... at the end of the day when you're coming from behind you just have to pay someone to port key pieces of software to your platform. AMD has really coasted for a long time on letting the open-source community do their work for them, but that's not going to fly with things like PyTorch or other key pieces of software... if AMD wants the sales and the adoption of their hardware, it's just going to have to pay someone to write the software, so that people who want to do research and not PyTorch maintenance can justify buying the hardware. I am not particularly interested in the perceived historical justifications for the current situation, it doesn't matter to the businesses who might be AMD's customers. And actually in many ways they've gotten even shakier recently, what with dropping RDNA support from their NN/ML package. As a cold statement of reality, this is table stakes going forward and if AMD doesn't want to do it they won't get the sales. It's not even just PyTorch either, it's... everything. AMD is just coming from a million miles behind on the software, and "welp just write it yourself if you want to use our hardware" is not an attitude that is conductive to selling hardware.

rektide 4y ago
Which libraries is AMD dropping RDNA support in? That seems very inadvised. Nvidia's libraries being usable by a broad range of developers on a wide range of hardware is critical to their wide adoption. AMD cannot expect to have real adoption if only their fancy enterprise grade unobtanium cards support ML systems. AMD needs a wide & engaged community trying to yse their stuff to figure out what software/drivers they simply have to build.
- paulmd 4y ago
  Talking specifically about ROCm here, their ML package. God this is such a tough paragraph to write accurately. AMD themselves have conflicting information all over their docs and repos and half of it is not even marked as "outdated"... https://docs.amd.com/bundle/ROCm-Getting-Started-Guide-v5.2.3 https://docs.amd.com/bundle/ROCm-Getting-Started-Guide-v5.2.... The official supported platforms at this point are RDNA2 (pro), GFX9 (pro), and CDNA. Consumer versions of these (RDNA2, Radeon VII, and Vega 56/64) probably work, although Vega 56/64 are an older version with much less hardware support as well. RDNA2 support is also "partial" and ymmv, things are often broken even on supported cards. If RDNA2 works, then RDNA1 may work, but again, mega ymmv, things may not even be great with RDNA2 yet. The "hardware guide" link talks about supporting Vega 10 (that's V56/64) and says GFX8 (Polaris) and GFX7 (Hawaii) are supported... but that doc is tagged 5.0 and 5.1 was the release that dropped the other stuff. So I'd say Vega 64/56 chips are probably broken at this point, on the current builds. Up until earlier this year though, it was unsupported on any consumer card except Radeon VII. They dropped Hawaii/Polaris/Vega support about 6 months before they started adding partial RDNA2 support back. And in contrast... NVIDIA's shit runs on everything, going back 10 years or more. At least to Kepler, if not Fermi or Tesla uarch (GTX 8800 series). It may not run great, but CUDA is CUDA, feature support has been a nearly forward ratchet, and they've had PTX to provide a rosetta stone in between the various architectural changes. I mean... at the end of the day the hardware hasn't changed that much, surely you can provide a shader fallback (which is required anyway since RDNA2 doesn't have tensor acceleration). I don't get what the deal is tbh. https://www.techpowerup.com/288864/amd-rocm-4-5-drops-polaris-architecture-support https://www.techpowerup.com/288864/amd-rocm-4-5-drops-polari... https://www.phoronix.com/news/Radeon-ROCm-5.1 https://www.phoronix.com/news/Radeon-ROCm-5.1