The conversation

Lessons learnedExperience excerpt · English

I made an attempt a few years ago at getting in to the machine learning world and discovered very …

… I made an attempt a few years ago at getting in to the machine learning world and discovered very quickly that I was facing a choice - either I could go AMD and open source drivers or Nvidia and cutting edge software. To learn the algorithms on my own PC just didn't seem feasible with an AMD GPU - running them on the CPU was too slow and I never found a way to make things work on the GPU with the resources I located. I gave up on AI since open source software is more important to me. Maybe I just lacked the right mindset, but the difficulties were so extreme it seems plausible that most people with an AMD GPU ever learned to use ROCm at the amateur level and there wasn't a sufficiently good strategy to get it adopted at the professional level without an amateur community. Low GPU programming is really hard. OpenGL, CUDA, OpenCL, whatever. I'm still on the lookout for an introductory resource on how I'm meant to use an AMD gpu to multiple 2 matrices together. I literally can't find one with a 5 minute google search, I get a blank article [0]. Maybe it is just blank for me? …

Original discussionAMD ROCm: A Wasted Opportunity101 source comments · at import
3

What was this responding to?

Parent context · original excerpt

DO

The way ROCm has turned out is such a shame. It really is effectively an advertisement for CUDA and served exactly that purpose for me. Even Intel's oneAPI stuff seems to be heading in a more viable direction. I feel like AMD for some reason doesn't understand that support for GPGPU on the consumer stack is important to eventually getting adoption in the enterprise space. CUDA is so convenient in part because as long as you have an NVIDIA card it'll probably be usable for testing, even if not necessarily optimal or fast. Then, once confidence has been built about its usability, a more serious investment can be made into getting the more powerful cards.

Full original

Community replies 0

No community replies yet. Add your perspective.

Replies from the source 3

Direct replies available in this import. Original-language excerpts.

HE

ROCm is a mess and I am similarly disappointed in AMD for the same reasons. Using AMD GPUs for accelerated compute on Linux is buggy and disappointing even if you get close to making it work.

Full original
TO

Moreover they screwed over a big chunk of the people willing to use their hardware and their OpenCL stack (who might have migrated to ROCm if there was a not too painful path) when they EoLed their embedded GPU offer out of the blue. Now your options are TigerLake (and who knows whether Intel is going to keep the sycl/oneAPI support up, and I don't feel Intel really serious about GPUs in the long term... Or even in the 'open standard' shtick they're selling on oneAPI/SYCL) or NVIDIA and the CUDA collar.

Full original
PA

PyTorch would probably be the easiest way to get started there, it should give you a NumPy style handle into high-level objects. As far as low-level, OpenCL has always had a horrendous amount of boilerplate just to get started, CUDA is a little better. One thing that can help is Thrust framework on CUDA, which attempts to provide a C++ STL-style interface to GPU operations. I am not saying it's super performant but especially it can give you a place to start and handle some of the boilerplate automatically. In classic AMD fashion there is a me-too copy that hasn't been updated in like 5+ years, probably was some intern's summer project or some employee's resume-driven-development thing and AMD has just always left this trail of abandoned projects in their wake. https://thrust.github.io/ https://hsa-libraries.github.io/Bolt/html/ But basically what this is going to look like is a main…

Full original
Continue on Hacker News

Respect different perspectives. Share concrete experiences.

Sign in to post, reply, repost, and quote.