5 ms·
The underinvestment in, and abandonment of, a project for a CUDA compatibility layer https://github.com/vosen/ZLUDA?tab=readme-ov-file#faq https://github.com/vo
by btown 2y ago
The underinvestment in, and abandonment of, a project for a CUDA compatibility layer https://github.com/vosen/ZLUDA?tab=readme-ov-file#faq https://github.com/vosen/ZLUDA?tab=readme-ov-file#faq by AMD a few months ago hints that they no longer see CUDA compatibility as a goal. Perhaps they see Silo as a way to jumpstart bringing ROCm to parity with CUDA's toolkit. It's hard to understand if there's an underlying strategy to how they'll stay relevant from a software perspective when they're abandoning projects like this.
Discussion: https://news.ycombinator.com/item?id=39344815 https://news.ycombinator.com/item?id=39344815
- seunosewa 2y agoThat's an unfortunate choice. AMD has excelled in making compatible hardware. Not so much software success, if any.
- Narhem 2y agoIt takes a lot of design skill to make something complex simple. I have a lot of doubt AMDs department even has design skills.
- Narhem 2y agoCUDA is a decided abstraction with OpenCL I wouldn’t be surprised if eventually they pick a different abstraction to describe the interface they use for writing programs
- IshKebab 2y agoIt makes no business sense for them to try to get CUDA compatibility. That would just cement CUDA as the de facto standard, at which point they are locked in to playing catch up forever as nVidia intentionally adds features to break compatibility. Much more sensible to work on getting rock solid support for their own standards into all the major ML platforms/libraries.
- joe_the_user 2y agoIt depends what means by "business sense". Compatible makers have profited, did profit during PC era. Indeed, one of AMD's core businesses is make xx86 compatible CPUs. Nvidia and standard-maker is limited in what breaking changes they introduce - these can harm their customers as much as they harm the competition. Intel failed to force all their changes on AMD as the xxx86 market expanded (notably, the current iteration of CPUs standards was set by AMD after Intel was unable to sell their completely new standard). Still, I'd acknowledge that "business sense" today follows the approach of only aiming for markets the company can completely control and by that measure, CUDA compatibility isn't desirable.
- mandevil 2y agoI think the key is that CUDA is much more like the Microsoft Windows software part of the duopoly than the Intel x86 hardware part of the old Wintel duopoly. At best back in the glory days of that era, you could have weird hackish things like WINE ... until Microsoft's business model changed and started being interested in supporting virtualization to build up Azure. The key is that while there were many clones of x86, there never really was an attempt at a company built around "run MS Windows programs natively" because maintaining software compatability is an order of magnitude harder than doing it for hardware.
- joe_the_user 2y agoCUDA is absolutely not equivalent to Windows as a platform. It's essentially a single API, not a huge, multilayer and futzy platform with multiple weirdly behaved APIs. Moreover, companies aren't buying GPUs to keep their huge stable of legacy applications running. They want to create new AI applications and CUDA is a simple API for doing that (at a certain level).
- mandevil 2y agoCUDA is a programming language with libraries (cuBLAS, cuSPARSE, etc.) that are constantly having things added and try to maintain backwards compatibility. It's not as big and hefty as all of Win32 sure, but it's still far more difficult than x86 compatibility.
- slashdave 2y agoThey don't need parity. They just need ROCm (or OpenCL) to be a reasonably viable alternative.