well, today i (partially) realized why my basic drivers don’t work: the preinstalled packages amdgpu and amdgpu-dkms seem to not work due to amdgpu-dkms being unconfigured. tried configuring it and got the same error. around about there my system stopped using even the iGPU and i had to uninstall some other drivers (thanks @lena@gregtech.eu )
AMD drivers are plug n play? They are part of mesa and you don’t need to do anything, why would you need to install anything else?
Edit: except rocm
Rocm unfortunately.
ROCM is well supported by docker PCI passthrough with official packages. So much better than polluting your workstation and maintaining the stack
Even ROCm on some distros isn’t that bad. On my 7900 XTX (admittedly an officially supported card, your mileage may vary on unofficial cards) on Fedora it was just a case of doing
sudo dnf install rocm-*and everything installed (might be some extra packages you need after for specific apps, but you know if you need them). On openSUSE though, it was a total pain.Don’t they support like 3 cards?
Rocm usually needs an override line in pip wheel/python, not the driver itself at least from my experience
Which distro are you using? AMD has been completely plug-and-play for me.
My R9 390 was a huge pain in the ass to get working on any distro, but I think it was the last card before they fixed whatever issue it was.
Yeah, afaik it’s exactly one of the cards that require manual intervention or a switch to the radeon driver. Bad generation to run on Linux.
I have a r9 380. It’s been amazing on Linux
This was on Windows:
Fancy.
As a relative Linux noob and Nvidia card owner, I keep hearing how it’ll be so much easier if I go AMD. Is that not true?
You typically only have issues if you want to use a newly released card with a distro that doesn’t run a recent kernel or if you want to use GPU compute.
Generally yes, if you use any modern card. Older ones might require to switch to an older driver (before “amdgpu” there was one called “radeon”, by default any distro I know comes with the modern amdgpu). There are also two AMD GPU generations (I think HD7000/Rx 200 and Rx 300) that can be a little bit nasty as the driver change happened around that time, those sometimes need manual intervention.
Anything newer (RX 550 and higher) pretty much always work without any hitch or additional steps required.
AMD used to be a huge pain in the ass to get working, but that hasn’t been true for a while now.
I can guarantee you’ll get more bang for your buck going with Nvidia just due to the fact that so much compute software requires cuda (blender, machine learning, any sort of engineering simulation software). Nvidia drivers are just less of a pain to deal with as a developer, since they’re less strict on error handling and syntax.
You can get a 3050 on amazon for like $150 now, which is more than enough for most games.
Plus DLSS is still miles ahead of FSR in terms of quality and efficiency.
Interesting! Well I currently have a 1070ti, which the internet tells me will mostly outperform a 3050. Thanks for your dev perspective.
Ive had no issues, nvidias just better when it comes to actual software support, like for blender, amd works mostly fine for me on cachyos, hip rt crashes blender tho. All of my steam games run fine. I did have to reinstall my os after messing stuff up setting up qemu, attaching my gpu as a device did not go correctly and when I removed qemu through the terminal (black screen) it stayed stuck on my integrated gpu and couldn’t recognize the seperate one anymoere. Only issue ive really had, wont try to set up a windows virtual desktop again.
nvidias just better when it comes to actual software support
Lol no.
Most local AI apps have cuda support for local GPU, only a few have rocm
Oh, that way around. Yeah, more software is using Nvidia CUDA although you can run increasingly more stuff via ZLUDA. Also more and more software comes around supporting ROCm or just uses a vulkan layer. In the end the biggest struggle is to install either CUDA or ROCm drivers, both can be lretty annoying to install depending on your distro. For local AI apps just use the ones supporting ROCm. Haven’t gotten into trouble there so far.
sudo pacman -Sy mesa vulkan-radeon (or smth like that)
Edit: Yeah, I know, Syu. I very rarely not do Syu. But /usr/bin/brain segfaulted while trying to be smart.
-Sy is recommended against. -S or -Syu, but not -Sy
Can I ask why? I’m newer to Arch and I legit don’t know.
Same question for me. I’ve never heard this.
-S means sync, or to install/update a package
y means to update the local package db, so which packages are available and especially which version is newest
u means update the packages themselvesSo -Sy would just get which newest packages are available, and then install eg. mesa version 6.9. However, mesa version 6.9 may depend on ligmalib 3.2. However, because you didn’t specify -u, ligmalib 3.1 is not updated to 3.2. And then you have a partial update.
Arch’s package system basically relies on all packages in all single points in time being compatible with each other. So if you look at the db now, all packages should have the correct versions of dependencies available. But if you mix different states, eg. update a few packages at 2:00 and some others at 17:00, that’s not given anymore
@sudoleah @myersguy this will refresh db without updating system and install package. If new package depends on newer libraries than other installed packages, it will break dependencies for installed packages. That might be easily solved with local solib dependency tracking (like gentoo preserved-libs database), but arch does not have it.
Yeah, only thought that halfway through lol
@30p87 @Fortatech enjoy ur broken system after partial update
I had to install a pacman package and change a config so my system would use vulkan instead of opengl. Other than that, nothing should be needed.
