3 ms·

I don't really think this was in AMD's best interest when you think about it strategically. Unless it were production-grade and legally tested, it's basically a

by bri3d 3y ago

I don't really think this was in AMD's best interest when you think about it strategically. Unless it were production-grade and legally tested, it's basically a tool that would enable developers to build applications using AMD and then deploy on NV. Perhaps a short term win on the consumer card side, but a long term foot-gun that would only serve to continually entrench NV in the datacenter.

outworlder 3y ago
That's a problem indeed, since it would further entrench CUDA. If you want people to develop for your platform, it could be counter-productive. That said, what _is_ AMD's platform? OpenCL? Vulkan compute? If they don't have an alternative, then the strategy doesn't make sense.
- incrudible 3y ago
  > What is AMDs platform? That is a very good question that apparently AMD has no good answer for. I have lost track of the amount of half baked implementations for GPGPU that AMD has attempted and then left to rot. Even if they told me they had the answer now, and they are going to put all their focus on that, I would not trust them to deliver on it. Their best bet is to create implementations for popular libraries like torch that actually stand a chance to work as a drop in replacement.
  - happymellon 3y ago
    > I have lost track of the amount of half baked implementations for GPGPU that AMD has attempted and then left to rot. They heard that it was successful for Google?
  - claudex 3y ago
    That's exactly what they are doing https://rocm.docs.amd.com/projects/install-on-linux/en/develop/how-to/3rd-party/pytorch-install.html https://rocm.docs.amd.com/projects/install-on-linux/en/devel...
- zozbot234 3y ago
  Vulkan Compute is not AMD-specific in any way, it should "just work" on any Vulkan-capable GPU including integrated ones.
- bee_rider 3y ago
  A problem is probably that there is that there are just a ton more Nvidia cards out there, and CUDA is hard to keep up with, so nobody is doing to invest in an alternative more open language. A possible solution (that doesn’t involve being better than Nvidia at the things they are good at, which seems to be impossible) is to create frameworks that spit out CUDA or, whatever, OpenCL. Nobody actually wants to use the languages, right? Everybody loves CuBLAS and CuDNN, not CUDA, make GPUOpenBLAS. Maybe they could get Intel to come along with them.
  - bri3d 3y ago
    That's literally what they're doing. HIP supports Nvidia as a backend, and AMD are making replacements like MIOpen, which is intended as a quick-port replacement for cuDNN.
- bri3d 3y ago
  HIP/ROCm is the direct equivalent to CUDA (with MiOpen as the cuDNN equivalent). It's actually Not Bad, although it is pretty AMD-typically buggy.
incrudible 3y ago
What is the alternative? Build their own API that expects developers who have been burned by AMD again and again to provide dedicated support for? Good luck with that. CUDA is already entrenched, NVIDIA hardware is already deployed, so as a developer I can’t not support it. Why would I then go out of my way for the single digit percentage of users that need AMD support?
- bri3d 3y ago
  I think they're betting that as NVIDIA hardware gets more expensive and harder to get, especially in the datacenter, there's now an opportunity to entice developers to take on the pain of porting to HIP/ROCm. Nobody cares about "users" in this case, it's bespoke applications running on bespoke infrastructure at scale.
  - incrudible 3y ago
    AMD is just as fabless as NVIDIA, both compete for production capacity, and eventually TSMC etc will get around to producing more chips than the market will want to buy.
Steltek 3y ago
Instead customers buy and develop on Nvidia and then deploy on Nvidia leaving AMD with nothing at all. "Production grade" feels pretty ambiguous. It either works or it doesn't for any particular developer's use case.

by bri3d 3y ago

outworlder 3y ago

That's a problem indeed, since it would further entrench CUDA. If you want people to develop for your platform, it could be counter-productive. That said, what _is_ AMD's platform? OpenCL? Vulkan compute? If they don't have an alternative, then the strategy doesn't make sense.

incrudible 3y ago
> What is AMDs platform? That is a very good question that apparently AMD has no good answer for. I have lost track of the amount of half baked implementations for GPGPU that AMD has attempted and then left to rot. Even if they told me they had the answer now, and they are going to put all their focus on that, I would not trust them to deliver on it. Their best bet is to create implementations for popular libraries like torch that actually stand a chance to work as a drop in replacement.
- happymellon 3y ago
  > I have lost track of the amount of half baked implementations for GPGPU that AMD has attempted and then left to rot. They heard that it was successful for Google?
- claudex 3y ago
  That's exactly what they are doing https://rocm.docs.amd.com/projects/install-on-linux/en/develop/how-to/3rd-party/pytorch-install.html https://rocm.docs.amd.com/projects/install-on-linux/en/devel...
zozbot234 3y ago
Vulkan Compute is not AMD-specific in any way, it should "just work" on any Vulkan-capable GPU including integrated ones.
bee_rider 3y ago
A problem is probably that there is that there are just a ton more Nvidia cards out there, and CUDA is hard to keep up with, so nobody is doing to invest in an alternative more open language. A possible solution (that doesn’t involve being better than Nvidia at the things they are good at, which seems to be impossible) is to create frameworks that spit out CUDA or, whatever, OpenCL. Nobody actually wants to use the languages, right? Everybody loves CuBLAS and CuDNN, not CUDA, make GPUOpenBLAS. Maybe they could get Intel to come along with them.
- bri3d 3y ago
  That's literally what they're doing. HIP supports Nvidia as a backend, and AMD are making replacements like MIOpen, which is intended as a quick-port replacement for cuDNN.
bri3d 3y ago
HIP/ROCm is the direct equivalent to CUDA (with MiOpen as the cuDNN equivalent). It's actually Not Bad, although it is pretty AMD-typically buggy.

incrudible 3y ago

What is the alternative? Build their own API that expects developers who have been burned by AMD again and again to provide dedicated support for? Good luck with that. CUDA is already entrenched, NVIDIA hardware is already deployed, so as a developer I can’t not support it. Why would I then go out of my way for the single digit percentage of users that need AMD support?

bri3d 3y ago
I think they're betting that as NVIDIA hardware gets more expensive and harder to get, especially in the datacenter, there's now an opportunity to entice developers to take on the pain of porting to HIP/ROCm. Nobody cares about "users" in this case, it's bespoke applications running on bespoke infrastructure at scale.
- incrudible 3y ago
  AMD is just as fabless as NVIDIA, both compete for production capacity, and eventually TSMC etc will get around to producing more chips than the market will want to buy.

Steltek 3y ago

Instead customers buy and develop on Nvidia and then deploy on Nvidia leaving AMD with nothing at all. "Production grade" feels pretty ambiguous. It either works or it doesn't for any particular developer's use case.