3 ms·
I'm talking about what would be the point for someone to add ROCm support to various pieces of software which currently require CUDA, as IMHO this is the core c
by PeterisP 3y ago
I'm talking about what would be the point for someone to add ROCm support to various pieces of software which currently require CUDA, as IMHO this is the core context not only of this thread but of the whole discussion of this article - about ROCm becoming a widely used replacement or alternative for CUDA.
> "ROCm is primarily targeted at discrete professional GPUs"
That's kind of true, and that is a big part of the problem - while AMD has this stance, ROCm won't threaten to replace or even meet CUDA, which has a much broader target; if you and/or AMD want to go in this direction, that's completely fine, that is a valuable niche - but limiting the application to that niche clearly is not "doubling down on ROCm" as a competitor for CUDA, and that disproves the TFA claim by Intel that "the entire industry is motivated to eliminate CUDA", because ROCm isn't even trying to compete with CUDA at the core niches which grant CUDA its staying power unless it goes way beyond merely targeting discrete professional GPUs.
- latchkey 3y ago> what would be the point for someone to add ROCm support to various pieces of software which currently require CUDA It isn't just old cards though, CUDA is a point of centralization on a single provider during a time when access to that providers higher end cards isn't even available and that is causing people to look elsewhere. ROCm supports CUDA through the included HIP projects... https://github.com/ROCm/HIP https://github.com/ROCm/HIP https://github.com/ROCm/HIPCC https://github.com/ROCm/HIPCC https://github.com/ROCm/HIPIFY https://github.com/ROCm/HIPIFY The later will regex replace your CUDA methods with HIP methods. If it is as easy as running hipify on your codebase (or just coding to HIP apis), it certainly makes sense to do so.