Fucking do it. Anything that takes down Nvidia’s CUDA Monopoly has my full support.
this post was submitted on 09 Sep 2024
296 points (99.0% liked)
Technology
58108 readers
3902 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
Squish them like bug. Show me you can do it, AMD.
Narrator: They couldn't.
AMD seems to be doing great: https://seekingalpha.com/article/4718576-amd-stock-ai-accelerators-drive-revenue-and-margin-outlook-upgrade-buy
load more comments
(6 replies)
Anything to help them take on Nvidia and stay competitive is a good move. However, I wish they would also announce a recommitment to driver and software stability. I had to move to Nvidia for my workstation rig after having constant stability issues with numerous AMD cards across multiple builds. I can handle a few rough edges or performance that isn't top-of-the-line but I can't put up with constant crashes ad driver timeout errors. It's annoying in games and devastating when I'm working.
I wish their GPU line received even a portion of the polish and care that their CPU line did.
As a Linux user, I had to trade in my Nvidia laptop for one with an AMD GPU due to how unstable the Nvidia drivers were and how many problems they were giving me. With the AMD laptop, I have had zero issues.
I did the same move for similar reasons! Although I still keep windows around on another SSS - and even the Windows Nvidia drivers were being funky for me.
Nvidia shares a lot of logic between their Windows and Linux driver as far as I'm aware, so I suppose it makes sense.
Damn, I've had the exact opposite experience. I had to move away from a 1080 Ti that I was having constant instability with, even after I went back to the retailer and got a new card.
Unfortunately at the time, AMD didn't have anything performance competitive. But it was worth the downgrade for the better drivers.
I had to move away from a 1080 Ti that I was having constant instability with, even after I went back to the retailer and got a new card.
Was it the card or was it something else? Any chance you have a 13th or 14th gen Intel CPU?
It was the card, and nah, it long predates 13th/14th gen.
Isn't it at meme levels when YouTube games have their screen go black and they mention Nvidia crashing?
The annoying part is their drivers are stable....sometimes.
Its an endless game of seeing if any specific version is broken in a way that annoys you and rolling back if you find an issue.
Not exactly a premium experience.
Even on Linux where their drivers are supposed to be better, my 7900XTX has been crashing randomly for at least a month and it was only fixed in the latest 6.10.9 kernel release yesterday.
Yeah I've heard the 'AMD drivers are better!' thing for Linux and have always been confused since I've had no issues with nVidia cards on Linux or Windows related to driver issues.
AMD stuff on the other hand, has been a mess non stop, except for my ROG Ally for some reason which is fine?
In short: computers suck and are unpredictable, or something.
Yeah, this too. My dad's last GPU was AMD and he had to flip flop between versions to fix crashes. I wasn't as lucky as no driver version was able to calm the crashing.
This checks out after what they recently did to the ZLUDA project. As an owner of an AMD gpu I agree that ROCM support is really bad. It works half of the time and fairly poorly.
Even worse on Linux. Even worse on more exotic distros like Bazzite where I still can't get koboldcpp to run, which was already kind of a hassle on my previous distro.
Yeah I hear ya. How do you happen to be running it? I use NixOS and its a challenge there for me but I found atleast some success using docker since the dependencies are so out of control for AI at the moment.
Also give Ollama-rocm + Open Webgui a shot as an alternative to koboldcpp if you cant get atleast some text generation to work because that is the only thing I have got working with rocm.
The trick to nixos, in this instance, is to use a python venv. Python dependencies are fickle and nasty in the first place, triply so when talking about fast-churning AI code, I tried specifying everything with nix, I succeeded, and then you have random comfyui plugins assuming they can get a writeable location by constructing a path from comfyui's main.py. It's not worth it: Let python be the only dependency you feed in, let pip and general python jank do the rest.
At the moment I just don't. I got kobolcpp to run through distrobox / boxbuddy but I can't get it to compile with rocm, so I can only use CPU generation, which is abysmally slow. Might go back to NovelAI when they release their new model if I can't find a solution.
What card do you use? I have a 6700XT and getting anything with ROCM running for me requires that I pass the HSA_OVERRIDE_GFX_VERSION=10.3.0 environmental variable to the related process, otherwise it just refuses to run properly. I wonder if it might be something similar for you too?
6650 XT.
Honestly no idea. When I run
make LLAMA_HIPBLAS=1 GPU_TARGETS=gfx1032 -j$(nproc)
in the Fedora distrobox on kobolcpp it throws a bunch of
fatal error: 'hip/hip_fp16.h' file not found
36 | #include <hip/hip_fp16.h>
errors and koboldcpp does not give an option to use Vulkan.
Ah, strange. I don't suppose you specifically need a Fedora container? If not, I've been using this Ubuntu based distrobox container recipe for anything that requires ROCM and it has worked flawless for me.
If that still doesn't work (I haven't actually tried out kobolcpp yet), and you're willing to try something other than kobolcpp, then I'd recommend the text-generation-webui project which supports a wide array of model types, including the GGUF types that Kobolcpp utilizes. Then if you really want to get deep into it, you can even pair it with SillyTavern (it is purely a frontend for a bunch of different LLM backends, text-generation-webui is one of the supported ones)!
I don't think so, it's just what I'm more familiar with and I usually try to avoid apt's PPA hell as much as I can. But maybe I should try some others, as I couldn't get Mullvad to run either yet. :/
Text gen web ui I tried quite a while before I went to koboldcpp on my previous distro and I could not get that to run without crashing whenever I tried to generate anything. Sillytavern is my standard frontend that I use, so any text gen software should inherently compatible with that anyway.
Hmm, gotcha. I just tried out a fresh copy of text-gen-webui and it seems like the latest version is borked with ROCM (I get the CUDA error: invalid device function error).
My next recommendation then would be LM Studio which to my knowledge can still output an OpenAI compatible API endpoint to be used in SillyTavern - I've used it in the past before and I didn't even need to run it within Distrobox (I have all of the ROCM stuff installed locally, but I generally run most of the AI stuff in distrobox since it tends to require an older version of Python than Arch is currently using) - it seems they've recently started supporting running GGUF models via Vulkan, which I assume probably doesn't require the ROCM stuff to be installed perhaps?
Might be worth a shot, I just downloaded the latest version (the UI has definitely changed a bit since I last used it) and just grabbed a copy of the Gemma model and ran it, and it seemed to work without an issue for me directly on the host.
The advanced configuration settings no longer seem to directly mention GPU acceleration like it used to, however I can see it utilizing GPU resources in nvtop currently, and the speed it was generating at (the one in my screenshot was 83 tokens a second) couldn't have possibly been done on the CPU so it seems to be fine on my side.
5500 here. I can't use any recent rocm version because the GFX override I use is for a card that apparently has a couple more instructions and the newer kernels instantly crash with an illegal operation exception.
I found a build someone made buried in a docker image and it indeed does work, without override, for the 5500 but it's using all generic code for the kernels and is like 4x slower than the ancient version.
What's ultimately the worst thing about this isn't that AMD isn't supporting all cards for rocm -- it's that the support is all or nothing. There's no "we won't be spending time on this but it passes automated tests so ship it" kind of thing. "oh the new kernels broke that old card tough luck you don't get new kernels".
So in the meantime I'm living with the occasional (every couple of days?) freeze when using rocm because I can't reasonably upgrade. Not just the driver crashes, the kernel tries to restart it, the whole card needs a reset before doing anything but display a vga console.
Yeah, I definitely am not a fan of how AMD handles rocm - there's so many weird cases of "Well this card should work with rocm, but... [insert some weird quirk that you have to do, like the one I mentioned, or what you've run into]".
Userspace/consumer side I enjoy AMD, but I fully understand why a lot of devs don't make use of rocm and why Nvidia has such a tight hold on things in the GPU compute world with CUDA.
CDNA is actually DNA made using RNA as a template. Very important for the viral ecosystem.
Don't forget mRNA in the process!
Could be mRNA. Could be gRNA. But I think this article wants them in all caps.
When AMD moved on from its GCN microarchitecture back in 2019, the company decided to split its new graphics microarchitecture into two different designs, with RDNA designed to power gaming graphics products for the consumer market while the CDNA architecture was designed specifically to cater to compute-centric AI and HPC workloads in the data center.
I wonder if CDNA will be more akin to Tensor Cores on RTX GPUs, leading to better ray tracing performance of gaming.
Tensor cores have nothing to do with raytracing. They're cut-down GPU cores specialising in tensor operations (hence the name) and nothing else. Raytracing is accelerated by RT cores, doing BVH traversal operations and ray intersections, the tensor cores are in there to run a denoiser to turn the noisy mess that real-time RT produces into something that's, well, not messy. Upscaling, essentially, the only difference between denoising and upscaling is that in upscaling the noise is all square.
And judging by how AMD has done this stuff before nope they won't do separate cores, but make sure that the ordinary cores can do all that stuff well.
Oh I see. So DLSS and especially ray reconstruction uses tensor core, would that be right?
I guess then it may be better to keep expectations low.
Yep that's what nvidia marketing seems to be calling their denoiser nowadays. Gods spare us marketing departments.
Fermi 2.0?
Or is this going to be more like kepler where the consumer grade stuff doesn't have all of the power hungry features, and the datacenter stuff gets them?
Will I even be able to afford one? Still rocking a Radeon VII here..
If you bought it for $700 back in the day, that's $1000+ in current dollars
Yep. My paycheck has sadly not scaled in a similar manner :(
view more: next ›