3 ms·

The way I see it, the whole point of ROCm support is being able to service the many users who have pre-existing AMD cards and nothing else available. If someone

The way I see it, the whole point of ROCm support is being able to service the many users who have pre-existing AMD cards and nothing else available. If someone is going to rent a GPU, I don't need to bother with adding extra features for them, because they can just rent a CUDA-capable GPU instead. I'm considering adding ROCm support for some ML-enabled tool - no matter if it's a commercial product or an open source library - the thing I need from AMD is to ensure that the ROCm support I make will work without hassle for these end-users with random old AMD gaming cards (because these are the only users who need the tool to have ROCm support), and if ROCm upstream explicitly drops support for some cards because AMD no longer regularly test it, well, the ML tool developers aren't going to do that testing for them either; that's simply AMD intentionally refusing to do even the bare minimum (do a lot of testing for a wide variety of hardware to fix compatibility issues) that I'd expect to be table stakes for saying that "AMD is doubling down on ROCm".

latchkey 3y ago
> The way I see it, the whole point of ROCm support is being able to service the many users who have pre-existing AMD cards and nothing else available. ROCm is a stack of a whole lot of stuff. I don't see a stack of software being "the whole point". > the thing I need from AMD is to ensure that the ROCm support I make will work without hassle for these end-users with random old AMD gaming cards (because these are the only users who need the tool to have ROCm support) From wikipedia: "ROCm is primarily targeted at discrete professional GPUs" They are supporting Vega onwards and are clear about the "whole point" of ROCm.
- 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.

latchkey 3y ago

> The way I see it, the whole point of ROCm support is being able to service the many users who have pre-existing AMD cards and nothing else available. ROCm is a stack of a whole lot of stuff. I don't see a stack of software being "the whole point". > the thing I need from AMD is to ensure that the ROCm support I make will work without hassle for these end-users with random old AMD gaming cards (because these are the only users who need the tool to have ROCm support) From wikipedia: "ROCm is primarily targeted at discrete professional GPUs" They are supporting Vega onwards and are clear about the "whole point" of ROCm.

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.