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

251–260 of 312 posts

Re: AMD may get across the CUDA moat

#251

Post by Qwertious »

ngcc_hk wrote: post #175
AnthonyMouse wrote: post #32

Earlier quoted context omitted.

That's mostly when there isn't a lot of price elasticity of demand. If you're Comcast and Verizon, each customer wants one internet connection and you're not going to change the size of the market much by offering better prices. If you're AMD and NVIDIA and lowering the price would double the number of customers, you might very well want to do that, unless you're supply constrained -- which has been the issue because…

Actually there is already a market like this they are in - game. Most Gpu used are low to mid-range see steam. The AI has to and will go down to that level for using or gaming. You cannot just have game for intel … you did. Then steam work hard and realize the steam deck. You can have total different software like j and a did. Hence you really can’t have 1 N to rule for long. Do thank for it and all the fish, without…

AI doesn't have all that much application to gamedev - people think "videogames have lots of AI", and don't realize that "game AI" and "stable diffusion/GPT AI" are about as related as Java and Javascript.

Game "AI" is meant to be fun to play (and win) against, they're not meant to be smart; that's why zombie games are so successful. Most "game AI" are finite state machines, throwing a neural network at the issue would be absurd overkill.

I'm sure there will be some AI applications in games (like procedural world generation or such, perhaps) but it's not the obvious connection that most people think.

Re: AMD may get across the CUDA moat

#252

Post by weebull »

mschuetz wrote: post #224
nextaccountic wrote: post #191

Earlier quoted context omitted.

> 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. What AMD really needs is to have 100% feature parity with CUDA without changing a single line of code. Maybe for this to happen it needs to add hardware features or something (I see people saying that CUDA as an API is very tailored to the capabilities of nvidia GPUs), I don't…

Not just feature parity, but proper UX. Things need to just work, without spending hours or days to make them work.

Blame Nvidia. They are the ones the got the industry hooked on a proprietry API.

Re: AMD may get across the CUDA moat

#254

Post by londons_explore »

JonChesterfield wrote: post #242
KeplerBoy wrote: post #108

Earlier quoted context omitted.

It must be a misnomer on PyTorch's side. Clearly it's neither CUDA nor OpenCL. AMD should just get it's shit together. This is ridiculous. Not the name, but the fact that you can only do FP64 on a GPU. Everybody is moving to FP16 and AMD is stuck on doubles?

FP64 is what HPC is built on. F32 works on the cards too (same rate or faster). I don't know the status of F16 or F8. Some architectures provide fast F16->F32 and F32->F16 conversion instructions so you can DIY the memory bandwidth saving - that always seemed reasonable to me, but I don't know if the AMD hardware people are/will go down that path.

More importantly, if you specify FP16, yet the hardware only supports FP32, then the library should emit a warning but work anyway, doing transparent casts behind your back as necessary.

Re: AMD may get across the CUDA moat

#255

Post by weebull »

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.

Re: AMD may get across the CUDA moat

#256

Post by sharonzhou »

ROCm is great. We were able to get run and finetune LLMs on AMD Instincts with parity to NVIDIA A100s - and built an SDK that’s as easy to use as HuggingFace or easier (Lamini). Or at the very least, our designer is able to finetune/train the latest LLMs on them like Llama 2 - 70B and Mistral 7B with ease. The ROCm library isn’t as easy to use as CUDA because as another poster said, the ecosystem was built around CUDA. For example, it’s even called “.cuda()” in PyTorch to put a model on a GPU, when in reality you’d use it for an AMD GPU too.

Re: AMD may get across the CUDA moat

#257

Post by distract8901 »

aftbit wrote: post #146
distract8901 wrote: post #130

Earlier quoted context omitted.

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…

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'm sure that I could have fixed it, but I gave up after spending multiple evenings on it. Have you ever spent hours debugging a system exclusively in text mode? It isn't fun. Reinstalling the OS takes less than 30 minutes. It's a clear choice for me

Re: AMD may get across the CUDA moat

#258

Post by orangetuba »

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.

Nvidia on Linux is more like running Windows 95 from the gulag, and you're covered in ticks. I absolutely detest Nvidia because of the Linux hell they've created.

Re: AMD may get across the CUDA moat

#259

Post by pjmlp »

JonChesterfield wrote: post #245
nextaccountic wrote: post #191

Earlier quoted context omitted.

> 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. What AMD really needs is to have 100% feature parity with CUDA without changing a single line of code. Maybe for this to happen it needs to add hardware features or something (I see people saying that CUDA as an API is very tailored to the capabilities of nvidia GPUs), I don't…

The idea was supposed to be people convert cuda to hip, which is a pretty similar language, either by hand or by running a tool called 'hipify' that comes with rocm. You can then compile that unmodified for amdgpu or for nvptx. I think where that idea goes wrong is in order to compile it unmodified for nvptx, you need to use a toolchain which knows hip and nvptx, which the cuda toolchain does not. Clang can mostly co…

Both ideas are already lost before starting, Hip isn't polyglot as CUDA, and OpenCL is mostly stuck in C.

Re: AMD may get across the CUDA moat

#260

Post by MegaDeKay »

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 run Arch as well and AMD is only "good". I would have a problem every now and then where my RX560 would lose its mind coming out of sleep and I'd have to reboot.

But the other problem that really bugs me is the "AMD reset bug" that you trip over with most AMD GPUs. This is when you pass through a second GPU through to another OS running under KVM, and is what lets you run Linux and (say) Windows simultaneously with full GPU hardware acceleration on the guest. The reset bug means the GPU will hang upon shutdown of the guest and only a reboot will let you recover the card. This is a silicon level bug that has existed for many years across many generations of cards and AMD can't be arsed to fix it. Projects like "vendor-reset" help for some cards, but gnif2 has basically given up (he mentioned he even personally raised the issue with Lisa Su). Even AMDs latest cards like the 7800 XT are affected. NVidia works flawlessly here.

Post reply on HN