Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AMD may get across the CUDA moat

hpcwire.com

Post reply on HN
Print view View original

271–280 of 312 posts

Re: AMD may get across the CUDA moat

#271

Post by anon291 »

hot_gril wrote: post #80
fluxem wrote: post #65

I call it the 90% problem. If AMD works for 90% of my projects, I would still buy NVIDIA, which works for 100%, even though I’m paying a premium

I'm lazy, so it's 99% for me. I don't even mess with AMD CPUs; I know they're not exactly the same instruction set as Intel, and more importantly they work with a different (and less mainstream) set of mobos, so I don't want em. If AMD manages to pull more customers their way, that's great, it just means lower Intel premium for me.

I have no idea what you're talking about. Amd and Intel match on the isa in any case you'd see typically. Moreover, Intel is currently using AMDs instruction set. X86_64 was designed my amd and used to be called AMD64

Re: AMD may get across the CUDA moat

#272

Post by pixl97 »

mikepurvis wrote: post #121
xahrepap wrote: post #105

Earlier quoted context omitted.

I know it's still different than what you're looking for, so you probably already know this, but many projects like this have the Dockerfile on github which shows exactly how they set up the image. For example: https://github.com/RadeonOpenCompute/ROCm-docker/blob/master... They also have some for Fedora. Looks like for this you need to install their repo: curl -sL https://repo.radeon.com/rocm/rocm.gpg.key | apt-key…

Oh yeah, I mean... having the source for the container build is kind of table stakes at this point. No one would accept a 10gb mystery meat blob as the basis of their production system. It's bad enough that we still accept binary-only drivers and proprietary libraries like TensorRT. I think my issue is more just with the mindset that it's okay to have one narrow slice of supported versions of everything that are "kno…

> No one would accept a 10gb mystery meat blob as the basis of their production system

Heh, if only. When working with F100's I've seen many terrible, terrible things.

Re: AMD may get across the CUDA moat

#273

Post by ealloc »

LoganDark wrote: post #264
falconroar wrote: post #262

Is there any reason OpenCL is not the standard in implementations like PyTorch? Similar performance, open standard, runs everywhere - what's the downside?

IIRC, ease of implementation (for the GPU kernels), and cross-compatibility (the same bytecode can be loaded by multiple models of GPU).

How is CUDA-C that much easier than OpenCL? Having ported back and forth myself, the base C-like languages are virtually identical. Just sub "__syncthreads();" for "barrier(CL_MEM_FENCE)" and so on. To me the main problem is that Nvidia hobbles OpenCL on their GPUs by not updating their CL compiler to OpenCL 2.0, so some special features are missing, such as many atomics.

Re: AMD may get across the CUDA moat

#274

Post by pixl97 »

kkielhofner wrote: post #261
mr_toad wrote: post #203

Earlier quoted context omitted.

People use flakey software all their time. As long as it mostly works most of the time most people put up with it. Examples: Windows in the 90’s and 00’s, or any AAA game on first release in the last 10 years.

I have a friend at the Facebook AI Research lab and I assure you they would not tolerate any level of fundamental flakiness from their 8,000 GPU cluster. Talent, opportunity cost, and time to market in general is so crucial in AI no one has any time or patience for the "oddball Linux desktop" experiences people are describing here. Gaming users may tolerate some flakiness for their hobby but these AI companies dealin…

My guess is when FB does run into such flakiness they email ____.____@nvidia.com as part of some support contract they have and go "Yo, we see this issue, figure it out and fix it".

But I can promise you after reading things like the LKML for decades and a number of different Microsoft blogs, that everyone on this planet experiences flakiness issues at times and has to figure out how to adjust their workload to avoid it until the issue is discovered and fixed.

Re: AMD may get across the CUDA moat

#275

Post by gymbeaux »

anthk wrote: post #237
gymbeaux wrote: post #155

Earlier quoted context omitted.

I often have issues booting to the installer or first boot after install with an NVidia GPU. Pop_OS, Fedora and OpenSUSE work out of the box. Those are all Wayland I believe. Debian/Ubuntu distros are a bad time. I think they’re still X11. It’s ironic because X11 is supposed to be the more stable window manager.

X11 is not a window manager.

Xorg

Re: AMD may get across the CUDA moat

#276

Post by __rito__ »

iopq wrote: post #228
aftbit wrote: post #146

Earlier quoted context omitted.

As a counter-argument, I ran Arch Linux + nvidia GPUs + Intel CPUs between 2012 and 2020, and still run Arch + nvidia (now with AMD CPU) to this day. I won't say it has been bug free at all, but it generally works pretty well. If you find a problem in Arch that you cannot fix without reinstalling, you do not sufficiently understand the problem or Arch itself. "Installing" Arch is refreshingly manual and "simple" comp…

I tried using an Nvidia card with OBS to record my screen and it kind of freezes in Wine. I switched from x11 to Wayland and now Wine shows horizontal lines (!) and performs like crap. Even my 4GB RX 570 from years ago gives a better experience doing this. You just install OBS from flathub, Wayland works, everything works without any setup or tinkering. You click record and you can record your gameplay footage.

I use OBS on Linux with NVIDIA card fairly regularly.

It works flawlessly.

Never used Wine + OBS, though.

Re: AMD may get across the CUDA moat

#277

Post by kkielhofner »

pixl97 wrote: post #274
kkielhofner wrote: post #261

Earlier quoted context omitted.

I have a friend at the Facebook AI Research lab and I assure you they would not tolerate any level of fundamental flakiness from their 8,000 GPU cluster. Talent, opportunity cost, and time to market in general is so crucial in AI no one has any time or patience for the "oddball Linux desktop" experiences people are describing here. Gaming users may tolerate some flakiness for their hobby but these AI companies dealin…

My guess is when FB does run into such flakiness they email ____.____@nvidia.com as part of some support contract they have and go "Yo, we see this issue, figure it out and fix it". But I can promise you after reading things like the LKML for decades and a number of different Microsoft blogs, that everyone on this planet experiences flakiness issues at times and has to figure out how to adjust their workload to avoid…

He has described to me, in detail, some of the challenges they have had. I'm not saying it's exhaustive but I'm pretty sure if their experience with the fundamental software stack was what people here are claiming I would never hear the end of it.

Actually, no. Obviously they have Nvidia support but in one especially obscure issue he was describing Meta took it as an internal challenge and put three teams on it in competition. Naturally his team won (of course) ;).

Of course all software has flakiness - I'm not taking the ridiculous position that Nvidia is the first company in history to deliver perfect anything.

What I am saying is these anecdotal reports (primarily from Linux desktop hobbyists/enthusiasts) of "It's broken, it doesn't work. Nvidia sucks because it locked up my patched kernel ABC with Wayland XYZ on my bleeding edge rolling release and blah blah blah" (or whatever) are extreme edge cases and in no way representative of 99% of the Nvidia customer base and use cases.

Show me anything (I don't care what it is) and I'll find someone who has a horror story about it. Nvidia gets a lot of heat from the Linux desktop situation over the years and some people clearly hold an irrational hatred and grudge.

Nvidia isn't perfect but it's very hard to argue they don't deliver generally working solutions - actually best of breed in their space as demonstrated by their overwhelmingly dominant market share I highlighted originally.

Re: AMD may get across the CUDA moat

#278

Post by __rito__ »

distract8901 wrote: post #130
javchz wrote: post #26

CUDA is the only reason I have an Nvidia card, but if more projects start migrating to a more agnostic environment, I'll be really grateful. Running Nvidia in Linux isn't as much fun. Fedora and Debian can be incredibly reliable systems, but when you add an Nvidia card, I feel like I am back in Windows Vista with kernel crashes from time to time.

My Arch system would occasionally boot to a black screen. When this happened, no amount of tinkering could get it back. I had to reinstall the whole OS. Turns out it was a conflict between nvidia drivers and my (10 year old) Intel integrated GPU. But once I switched to an AMD card, everything works flawlessly. Ubuntu based systems barely worked at all. Incredibly unstable and would occasionally corrupt the output and…

I have used Pop OS and Ubuntu with NVIDIA card, and honestly, I never faced any serious problem.

After every kernel upgrade, I just have to reinstall the nvidia drivers and the cuda toolkit.

Everything works as before after I do that. I don't face any problems at all.

Re: AMD may get across the CUDA moat

#279

Post by jacobgorm »

LoganDark wrote: post #264
falconroar wrote: post #262

Is there any reason OpenCL is not the standard in implementations like PyTorch? Similar performance, open standard, runs everywhere - what's the downside?

IIRC, ease of implementation (for the GPU kernels), and cross-compatibility (the same bytecode can be loaded by multiple models of GPU).

The ease of implementation using CUDA means that your code because effed for life, because it is no longer valid C/C++, unless you totally litter it with #ifdefs to special case for CUDA. In my own proprietary AI inference pipeline I've ended up code-generating to a bunch of different backends (OpenCL SpirV, Metal, CUDA, HLSL, CPU w. OpenMP), giving no special treatment to CUDA, and the resulting code is much cleaner and builds with standard open source toolchains.

Re: AMD may get across the CUDA moat

#280

Post by physicsguy »

weebull wrote: post #255
physicsguy wrote: post #218

Don’t agree at all. PyTorch is one library - yes, it’s important that it supports AMD GPUs but it’s not enough. The ROCm libraries just aren’t good enough currently. The documentation is poor. AMD need to heavily invest in their software ecosystem around it, because library authors need decent support to adopt it. If you need to be a Facebook sized organisation to write an AMD and CUDA compatible library then the bar…

Disagree that the Rocm libraries are poor. Their integration with everything else is poor because everything else is so highly Nvidia centric, and AMD can't just write to the same API because it's copyright Nvidia (see Oracle's Java case). The adoption of CUDA has been such a coop for Nvidia, it's going to take some time to dismantle it.

I don’t use high level frameworks like PyTorch because my work is in computational physics so I do actually use the lower level libraries. The documentation doesn’t even come close although it has got better. But they’re just not at feature parity, and that’s not on anyone but AMD currently. They need to invest more in the core libraries.

Just look at cuFFT vs rocFFT for e.g… they aren’t even close to being at feature parity - things like multi GPU is totally missing and callbacks are still “experimental”. These are pretty basic features - bear in mind that when people ported from CPU codes CUDA had to support these because they existed in FFTW (transforms over multiple CPUs rather than GPUs though via MPI).

Post reply on HN