On NixOS, you can just remove the services.xserver.videoDrivers and hardware.nvidia.open options and rebuild π
this post was submitted on 29 Jul 2026
40 points (100.0% liked)
Linux
14472 readers
415 users here now
A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
founded 3 years ago
MODERATORS
Thanks, but NixOS was a bit too esoteric for me. I love the idea, but I could not wrap my head around the syntax no matter how many videos I watched or how much documentation I read.
That's fair. I noodled around with nix scripting and started my homelab replacement in a VM for months before I committed to the switch. I feel like a lot of tutorials out there are kind of hand-holdy so you don't really get to understand what some things mean.
I switched from an Nvidia to AMD on catchy. There are instructions in the Wiki. https://wiki.cachyos.org/features/chwd/gpu_migration/
It worked for me with only one issue. When I booted up the first time, I had no signal to the monitor. No big deal, I just used SSH from another computer to install the AMD drivers and update the bootloader.
Perhaps I can do the installation just before making the swap. Good to know!
Can you describe the process of installing AND drivers in this environment? It should be plug and play, though admittedly this was my experience with EndeavourOS, I've not yet tried Cachy
Look to the wiki link in my previous post for details, but the basic procedure was to uninstall the Nvidia drivers, shut down, install the new card, boot up and install the AMD drivers (there is a command to automatically detect your card and select the appropriate driver from the repos), and update the bootloader. I ended up having to do the second half through SSH, but otherwise a pretty painless process.
That's really peculiar, both the kernel mode and userspace drivers are included by most disteos by default, but I can totally understand the nv proprietary driver making a significant enough change that users will need to address when swapping to Intel or AMD dgfx
Thatβs what I thought, but bazzite didnβt like the switch from Nvidia to AMD either so idk whatβs going on with these distros.
I game on a 7900xtx on CachyOS and it's perfectly fine. Cachy will take care of the drivers 100% so it's just plug and play. Better than my previous 3080ti. No driver issues or whatever. LMK if I can answer any questions
Oh nice, so you swapped from a 3080ti to a 7900XT?
Yep yep
If any of your workflows rely on cuda (or any form of gfx compute), you may have a difficult time achieving comparable performance. hopefully rocm is directly packaged for arch + derivs soon, like it is with Fedora, as you'll be able to use that codepath for OpenCL if they don't directly offer support for HIP or ROCm.
My typical hangups there would be like, digital film production and other forms of rendering, CAD, physics simulations, and client apps like Folding@home.
Actually, there is one more package you might need: vulkan-radeon. The nvidia package, which you can remove then, provided that implementation itself.
huh, that's interesting. what does that provide to the system? Is that like having the lunarg loader present on a windows install?
It basically allows vulkan, the graphics engine, to work with AMD driver (which resides in the kernel). For OpenGL to work with it, you need the mesa package, but that's usually installed anyway.
Edit: graphics API, not engine
Isn't that part already covered by the radv mesa driver? I'm really confused. did you mean to refer to vulkan as a 3D gfx API rather than an engine? Or are there specific rendering engine workarounds included in the aforementioned package?
mesa only coveres, OpenGL, according to the arch wiki.
also, the former, I couldn't remember the correct word
That's not correct, though it may be ASIC specific. Can you tell me which GPU you're using?
IME, GCN4 and up are all seamlessly served by the radv mesa driver. If this person upgrades to a newer AMD GPU, they will not need to manually install a Vulkan ICD
To add, there are mesa vulkan drivers for Intel (ANV, which is the original basis of RADV), nvidia (NVK), Qualcomm (Turnip), and Apple Silicon (forgot the name but something apple-y I hope), and several others.
I'm not sure if there's any caveats specific to arch, I've not used it much outside of EndeavourOS, and primarily use Fedora, though the former was a completely plug and play experience across several systems with various generations of AMD graphics.
I've just always followed the Arch wiki, and never tried using Vulkan without vulkan-radeon on my one PC with an AMD card. The wiki states: "Install the mesa package, which provides both the DRI driver for 3D acceleration and VA-API/VDPAU drivers for accelerated video decoding." and "For Vulkan support install vulkan-radeon (lib32-vulkan-radeon for 32-bit applications).".The vulkan page itself says:
To run a Vulkan application, you will need to install the vulkan-icd-loader package (and lib32-vulkan-icd-loader from the multilib repository if you also want to run 32-bit applications), as well as Vulkan drivers for your graphics card(s). There are several packages providing a vulkan-driver and lib32-vulkan-driver:
AMD: vulkan-radeon (or lib32-vulkan-radeon)
Intel: vulkan-intel (or lib32-vulkan-intel)
NVIDIA: there are two implementations:
nvidia-utils (or lib32-nvidia-utils) - NVIDIA proprietary
vulkan-nouveau (or lib32-vulkan-nouveau) - NVK (part of Mesa project)
The vulkan-radeon package provides the ICD (
# pacman -Qlq vulkan-radeon | grep -v '/$'
/usr/lib/libvulkan_radeon.so
/usr/share/drirc.d/00-radv-defaults.conf
/usr/share/licenses/vulkan-radeon/license.rst
/usr/share/vulkan/icd.d/radeon_icd.json
); so does nvidia-utils (
# pacman -Qlq nvidia-utils | grep -i icd | grep -v '/$'
/usr/share/vulkan/icd.d/nvidia_icd.json
/usr/share/vulkansc/icd.d/nvidia_icd_vksc.json
)
, but mesa does not.
That's interesting. You generally don't need to manually install that. You've prompted me to play around with arch once I return from the most beautiful city in the world.
Which distro and dgpu are you using, if you don't mind me asking?
Updated the comment. (The ICD is explicitly installed by vulkan-radeon, vulkan-intel or nvidia-utils/vulkan-nouveau. Just as with all linux-firmware categories/companies being their own package now, this is probably done to minize unused space/bloat.)
Vanilla Arch Linux, testing repos, with an RX 7800XT.
This. As far as general 3D work, nope, just install the card and the drivers and off you go.
But if you want to do any compute stuff on the gpu you're in for a rough time. Like 95% of that software is targeted to Nvidia. There is a bit of work going on to adapt cuda stuff to AMD (rocm and hip like you mentioned), but most developers don't support it. Last time I tried (about a year ago), I was able to get about a quarter of the software I tried half working.
Thankfully, I don't do much GPU computing outside of simple video editing and games. Cuda was never a selling point for me; it was mainly raytracing, and generally speaking, I don't use it much anymore now that I've experienced the wow factor.
It's almost plug&play for you then. The only thing besides following the wiki that's already mentioned is to look up AMD specific Proton launch arguments like forcing games to use FSR4.
Oh, thank you! I would have absolutely missed that little detail.
No problem. There's also another handy tool here:
https://github.com/optiscaler/OptiScaler/blob/master/Spoofing.md#linux
You can spoof DLSS support and actually use FSR4 instead with games that don't officially support FSR, quite handy.
Otherwise AFAIK the Proton command "PROTON_FSR4_UPGRADE=1" will only upgrade games officially supporting older versions of FSR.
You should be fairly well served then. reach out to us if you face any bottlenecks with gfx compute.
I can offer some distro-agnostic observations . . .
Having swapped from one to the other some time ago on Gentoo, what I had to (re)install was the kernel (since I'd built it without those drivers), mesa, and some xorg-drivers stuff (which may not be relevant to you). Also, LLVM (ugh), because the AMD drivers compile stuff on the fly somehow and gcc doesn't have a usable AMDGPU backend. Or something like that. At that point, the system should boot well enough to bring up the GUI, and you can worry about vulkan and such after that. If you have an initrd, that may need to be rebuilt or replaced. Bootloader should be fine if it's the same kernel version.
Having the kernel drivers for AMD present in a system with an nvidia card shouldn't present any problemsβwithout the hardware, the kernel won't even try to load them. In theory, you should even be able to have both cards in there at once (if your mobo has the slots) and blacklist the drivers for the card you don't want to use, but it isn't the safest thing to try.
Thanks, and that's what I was thinking might be the case. CachyOS has an easy tool for switching kernels, and I have a vague memory of needing to blacklist certain parameters during boot, but I'll have to look into that more. Somebody kindly shared a migration guide link elsewhere to look at, and I bet it talks about some of the things you've mentioned.
Hopefully I can get away without a reinstall!
If you get a 9070xt and want to avoid the 12vhpwr cable, look into XFX cards. Sapphire is a good brand but they use it.
I have one from Sapphire and it's been good so far thoughπ€
I know that's not what you asked about but I think it may be relevant to others if not to you
My Gigabyte "9070 XT GAMING OC 16G" has three 8-pin power connectors.
I slightly regret it because it's a 3-slot card and only has two DisplayPort outputs. I had to buy a new case for it, and my third monitor (on HDMI) doesn't behave quite as well as the other two. Almost a year and a half later and I'm still mildly annoyed that I didn't have the ability to return it in favor of a PowerColor Reaper once I realized my mistake.
I'm sure the Gigabyte card is fine if you have a normal size (not mini-ITX) case and only one or two monitors, though.
Handy to know! I would have had an XFX card, but the Nvidia card dropped in price first.
Personally, I'm less familiar with the full stack. I'd be tempted to do a reinstall. There's vulkan-radeon, vulkan-mesa linux-firmware-radeon, radeon, mesa, libs, layers, headers, and I'm not sure what uses what, but I have them all with my amd RX 6800 XT. Hopefully a pacman -Syu grabs what you all need.
I don't know about the 3000 series but when I went from a 970 to my 7900xtx, my old Linux kernel physically didn't even support it's basic VGA mode and I had to swap distros to get it to boot. That was like years ago and an old version of mxlinux though, so I doubt you'll have that issue.
I tried MX Linux, and it didn't work with my hardware at all! Something was broken with the desktop shell or window manager that drew everything in the wrong places
That's not to say it's bad, but it definitely isn't as plug-and-play as some other distros.
Maybe switch to a more generic kernel, and you might need the mesa drivers, but yeah otherwise it should work just fine!
Back in the day, NVIDIA was the most painful to get workin with ole tux and AMD was the better one. Don't know how it is now, but I think AMD is still decent for linux support
They're virtually comparable in features, but there's no denying that the more open nature of AMD naturally leads to fewer pain points. I haven't had any significant ones (and not ones I know would instead work with AMD), but there could be things that aren't working well now that I've just taken for granted, since I only have the one GPU.
Generally speaking, either GPU should work great for most people for common workloads.
further back in the day, nvidia were the only ones to provide competent support for Linux desktops. The fglrx days were rough!