5 ms·
It's absolutely absurd that AMD stopped funding this, since right as it got released as open source it started producing value for AMD users. You'd think this e
by Blackthorn 3y ago
It's absolutely absurd that AMD stopped funding this, since right as it got released as open source it started producing value for AMD users. You'd think this exact thing would be their top priority, but instead they've been faffing around for years with two (are they up to three now?) alternate APIs with minimal support so far.
- deleted 3y ago[deleted]
- bri3d 3y agoI 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 agoThat'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 agoThat'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 agoVulkan Compute is not AMD-specific in any way, it should "just work" on any Vulkan-capable GPU including integrated ones.
- bee_rider 3y agoA 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 agoThat'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 agoHIP/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 agoWhat 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 agoI 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 agoAMD 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 agoInstead 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.
- dkjaudyeqooe 3y agoIf it ever became a reliable option Nvidia would just send a cease and desist and then sue. It's a blind alley as a serious solution. It makes sense in that context.
- beeboobaa 3y agoWhy would software that lets me use hardware that I own, installed in my machine, be subject to a cease and desist?
- varelse 3y ago[dead]
- szundi 3y agoWelcome the the US when you can patent protocols and apis. (Afaik) In EU you could have done it but because of US risks they killed it anyway.
- bee_rider 3y agoIf it is totally fine in the EU, why not just host it there? Spain (or whoever) could start up a cottage industry of ignore-local-ip-law-as-a-service. The Uber of IP law.
- strangescript 3y agoI am sure they got the heads up about NVIDIA's announcement and cut this contractor loose. As per the contract agreement, the project would become open source.
- sfmike 3y agoinner taiwanese dealmaking in zhubei
- ActionHank 3y agoThe assumption here is that they chose to abandon it, what if they have something better they're building?
- deleted 3y ago[deleted]
- sva_ 3y agoIs it perhaps because they want people to use HIP? > HIP is very thin and has little or no performance impact over coding directly in CUDA mode. > The HIPIFY tools automatically convert source from CUDA to HIP. 1. https://github.com/ROCm/HIP https://github.com/ROCm/HIP
- eptcyka 3y agoThese help developers, ZLUDA could end up helping users.
- mardifoufs 3y agoIsn't it just a translation tool set? Can it translate actual CUDA code at runtime?
- entropicdrifter 3y agoNot at runtime, it translates the source, so HIPIFY can only be used before compile-time