There are many reasons to dislike Nvidia on Linux. Here is a little thing that bugs me all the time, the updates. Normally the system updates would be quick and fast, but with the proprietary drivers of Nvidia involved, it gets quiet slow process. And I am not even talking about any other problem I encounter, just about the updates.
As an Archlinux based system user (EndeavourOS to be precise), I get new Kernel updates all the time. That means every time a new Kernel version is installed, the Nvidia driver DKMS has to be installed too. And that is basically the slowest part. But that’s not too bad, even though it’s doing this twice for each Kernel I have once.
What’s more infuriating is, if you also happen to use Flatpaks for a very few applications. I really don’t have many Flatpaks at all. Yet, the Nvidia drivers are installed in 7 versions or what?! And they are full downloads, each 340 MB or more. This takes ages and is the only part that takes long to update Flatpak system. I always do flatpak remove --unused to make sure nothing useless is present. /RANT (EDIT: Just typos corrected.)
And in addition to that, it’s the only thing that breaks on my system that isn’t my fault.
My next GPU will definitely be AMD unless Intel catches up very quickly.
I bought a laptop with an AMD. It’s been awesome.
Same. Everything just works great out of the box.
I got both an AMD desktop and laptop GPU and I’ve had 0 issues with either. It’s been so refreshing.
I would have thought Intel would be decent on Linux. It falls behind on Windows because it doesn’t have all the years of broken game fixes baked into the drivers like AMD and nVidia have, but isn’t all the Linux gaming done through Vulkan wrappers around DirectX?
My embedded AMD GPU has been unusable under Ubuntu. Constant crashes/freezes. When trying to find a workaround (unsuccessfully), I found lots of other people with slight variations of the same problem - same symptoms, but different root causes… seems like at any time there are several system-breaking bugs and every time one is removed another is introduced. You just have to hope your kernel happens to be one that happens to work with your specific config.
My next platform will be Intel-based.
Can you use AMD CPU and Intel dGPU?
There’s been a long standing amdgpu bug over the past year, there is a Kernel flag that fixes it mostly. Haven’t had issues since the latest mesa and adding this flag. (RDNA3)
Just ubuntu or AMD APUs in general?
It works on Windows, no idea how other distros behave but judging by all the issues people were reporting, even if this specific issue doesn’t happen on other distros, you’ll get bitten by something else.
Of you have a thousand year old laptop with an amd embedded you can have such problems. Don’t draw the wrong conclusions about current Amd.
It’s less than 3 years old. If it was any newer the argument would be “you can’t expect such new hardware to be supported”.
That means every time a new Kernel version is installed, the Nvidia driver DKMS has to be installed too. And that is basically the slowest part.
ZFS users: “First time?”
@qwesx I am not familiar with ZFS filesystem. How does it affect this or plays a role?
My exact solution to this on Endeavour was to just stop using flatpaks lol.
Literally everything I used from flathub was also either on the AUR or trivial to install manually from the host GitHub.
Uses NVIDIA
Imaaaagine!
Seriously though, I feel for you. NVIDIA is shit and while you’re dealing with this, I hope you know which vendor you’ll not be giving money to in the future. Fuck NVIDIA.
@elouboub It’s AMD. 100% sure. And the best part is, the situation with Nvidia is nowadays improved. So this is the current best case we have…
I just switched from my 1060 3g to an rx580, because 3 gigs of vram is nothing on Linux. But good god, it’s so much better to use AMD on Linux. (Nvidia has fixed a tremendous amount of crap over the past 3 month (pretty much all the major issues with Wayland, Prime displays & even screen tearing are gone now & many of them were fixed just weeks ago), but as long as their driver has to be installed separately with a kernel module hook, it will never compare.
NVIDIA is shit
I would call that an exaggeration. It’s not perfect sure, but it has finally improved a lot in the last year and it works for some. I had to get a new gaming laptop earlier this year and the only good option I could afford had an NV card. It was a great deal from Bestbuy certified open box, $500 off (I love those open box deals with 30day return).
It works well, I play Guildwars2 and BG3 flawlessly through XWayland+proton with great performance. Maybe it works well because I put it into Dedicated Nvidia mode, instead of using Optimus? (I never liked Optimus)
Sure it’s not perfect, I get graphics glitches in KDE if bringing the laptop out of sleep, funny colors and a mouse with a funny trail, but I don’t need to use sleep, I boot it in the morning and shut it down in the evening, it’s no biggie for my use-case.
I doubt they’re all full downloads. Flatpak does a lot of deduplication. Flatpak will pretend to download 340MB for me, but the progress bar will freeze after 15MB and then continue onto the next item. You can see it in your screenshot as well, >140MB downloads that are marked as completed even though only a few megabytes were actually fetched. It still takes ages for it to extract on my machine (pretty sure it’s because btrfs is also deduplicating the files Flatpak is already deduplicating) but the sheer download size isn’t the problem in my experience. Not great, but not as terrible as it may seem.
Try this script, you may be surprised how much Flatpak object space is actually deduplicated.
The real issue in this case is the lack of updates from the applications you use. Seemingly abandoned Flatpaks depending on runtimes that went EOL months ago make the whole system very annoying to manage and it slows down the updater as well.
In your case I’d look into what applications are pulling in all of these Nvidia drivers and why, because it looks like they shouldn’t be.
I doubt they’re all full downloads. Flatpak does a lot of deduplication.
It downloads every single of them fully. Took 15 minute or so for all the packages or longer. This is going on since I started with Flatpak. The Nvidia drivers are not de-duplicated or partial downloads on my system.
You can see it in your screenshot as well, >140MB downloads that are marked as completed even though only a few megabytes were actually fetched.
That’s not the one I am complaining. The drivers are the ones named as
org.freedesktop.Platform.GL32.nvidia-xxx-xx-xx. These are the different driver versions of Nvidia and each of the 7 versions are 340 MB or more and are always downloaded fully. You can see each of them like 340,9 / 341,8 MB. What you was referring to is not what I am complaining. The extraction of the archives and installation is quick. Every other package is quick, only those take this long.but the sheer download size isn’t the problem in my experience. Not great, but not as terrible as it may seem.
It isn’t a hard problem, but very annoying. Not sure how fast internet access you have, I have under 7 MB/s. And only counting the Nvidida drivers through Flatpak alone is 2.3 GBytes. Imagine adding all the other updates in Flatpak, plus the system update of my OS itself and the DKMS. It adds up a lot.
If you have several kernels you might want to disable the fallback kernels. You do so in the .preset files in /etc/mkinitcpio.d/
But yeah this is the downside of using flatpaks. That’s why I think it’s better to avoid flatpaks and other similar sandbox environments. I know the Linux community are desperate for the increased stability and supposed benefits to security but you’re paying the price in worse performance and high disk usage.
I have an alias I call “upd” that runs “yay ; flatpak update”, I just run that, press Y at the first prompts and then let it run in the background while I do other work. It really doesn’t matter at all how long it takes. I do have NVidia but generally I don’t feel it takes very long as we don’t get new kernels every day. You could use the linux-lts kernel for much more rare kernel updates.
It’s a bit like bittorrents, I don’t need them to download in 30sec, I start it and return to check on it whenever I think of it.
I have changed my opinion on flatpak btw, I really like that the apps are not spread all over my system but instead sandboxed neatly, have fewer dependency versioning issues and it’s really easy to use.
The flatpak thing is a known issue, where it doesn’t correctly remove the 32bit package on update.
This bash script should find the latest and remove the rest:
#!/bin/bash # Filename: flatpak-clean-nvidia.sh # List latest 64bit Nvidia flatpak (it doesn't leave cruft behind) and note the version FLATPAK_LATEST_NVIDIA=$(flatpak list | grep "GL.nvidia" | cut -f2 | cut -d '.' -f5) # List all installed 32bit Nvidia flatpaks, ignore latest version, uninstall rest of list flatpak list | grep org.freedesktop.Platform.GL32.nvidia- | cut -f2 | grep -v "$FLATPAK_LATEST_NVIDIA" | xargs -o flatpak uninstallI switched from a 3070 to an Rx 7900XT on Sunday. Uninstalling all of nvidia shit was great. I used linux-zen so that meant using nvidia-dkms. So happy I don’t have to deal with that anymore. And yeah, I use a lot of flatpaks, so removing all of those nvidia drivers was also a great feeling. And now I can use Wayland!
@skulbuny I do not use zen and get the dkms. But honestly, the twice-dkms installation (one for each Kernel) isn’t too bad. The real issue for me is with Flatpak. I’m currently in the process of choosing and building new PC. Wish I could afford 7900XT, but together with an entire PC building it gets too expensive for me. Looking forward to AMD!
Which terminal font is that, by the way?
@aleph “Cascadia Code”
Here is fastfetch output:OS: EndeavourOS x86_64 Kernel: 6.1.51-1-lts Uptime: 50 mins Packages: 1149 (pacman), 34 (flatpak) Shell: bash 5.1.16 Display (AG271QG): 2560x1440 @ 120Hz DE: qtile WM: Qtile 0.22.1 (X11) Theme: Arc-Dark [GTK2/3] Icons: Qogir-dark [GTK2/3] Font: Cascadia Code (12pt) [GTK2/3] Cursor: Qogir Terminal: xfce4-terminal 1.1.0 Terminal Font: Cascadia Code (13pt) CPU: Intel(R) Xeon(R) E3-1230 v3 (8) @ 3,7 GHz GPU: NVIDIA GeForce GTX 1070 Memory: 3,11 GiB / 15,57 GiB (20%) Disk (/): 122,70 GiB / 227,21 GiB (54%) - ext4 Disk (/media/Backup): 149,83 GiB / 916,70 GiB (16%) - ext4 Disk (/media/Emulation): 3,83 TiB / 5,41 TiB (71%) - ext4 Disk (/media/My): 1,04 TiB / 3,58 TiB (29%) - ext4 Disk (/media/System): 411,39 GiB / 915,82 GiB (45%) - ext4 Locale: en_US.UTF-8
Thank you for not blaming maintainers who have no controlover nvidia idiocy.
Also why not mesa?
@uis I didn’t blame anyone particularly. I am just upset about the current situation as a Nvidia user. And it’s a warning to anyone who thinks about getting a Nvidia card on Linux.
Not sure why Mesa. It does not have the proprietary driver in it, does it?
It does not, that’s why I am suggesting it.
@uis Performance is the problem. I play games and there is no alternative to proprietary drivers.
What card you are using?
@uis GTX 1070. The new open source driver from Nvidia does not support the 10x series, if your question should lead to that. But does not matter, because yesterday all PC parts of my new build has arrived and I will set it up this weekend. AMD+AMD now. Finally done with these Nvidia frustration.
https://nouveau.freedesktop.org/FeatureMatrix.html says 1070 works fine, but without reclocking(on minimal speed). All thanks to nvidia DRM. And here DRM is not Direct Rendering Manager.
I will set it up this weekend. AMD+AMD now. Finally done with these Nvidia frustration.
Congrats!
@uis I know about nouveau which is community developed. This is what I meant with the performance. It’s not near on the same level as the proprietary. For gaming, this is not an option. But I thank you for the suggestions you made.
The best benchmarks I found is for the 20xx series, but look at the results to understand how big the difference is: https://www.phoronix.com/review/opensource-turing-3d/2
Dota 2:
- Noveau gets 7 fps
- Proprietary gets over 100 fps
That’s the level of difference we speak about.
You can manually remove all of the previous drivers and their GL32 counterparts, your flatpaks will still run as long as you have the newest drivers.
I’m not sure why they don’t get caught by the --unused flag, but they are definitely not needed from the flatpaks I’ve tested with.
I’ve kind of gotten used to the first issue already. I don’t know if I can switch to the non-DKMS drivers now that I’m using the LTS kernel though.
If you use the Zen kernel there is no reason to keep the regular one around.
I always did, saved my ass a couple of times when Zen broke.
I was wondering what the fuss was about until I read flatpak. I don’t use those, no reason to on Arch since everything is in the AUR. But it was interesting to read.
@1984 Unfortunately not everything is in the AUR or I do not want to trust everyone on the AUR. And there are other reasons to use Flatpak over native packaging (including AUR):
- kdenlive and Krita: I do not want to install the entire suite and dependencies of KDE.
- bottles: The Flatpak version is the recommended one by the devs and the only supported one I think.
- xemu: Yes it’s also available on, but I do not know who the uploader and manager of this binary is. While the Flatpak version an official package is.
- zeal: Same reason as xemu.
And that’s basically it (ok there is Flatseal too… but that does not count to our discussion). Everything else is installed through native packaging. So there is not much reason to use Flatpak and I just started with it recently. But there are sometimes reasons for.
