NVIDIA 520.56.06 driver adds easier NVIDIA NGX updates for Wine / Proton

Quoting: Marlock

Quoting: slaapliedjeAMD requires kernel updates and using out of band (meaning not the standard repository) mesa libraries (unless you're running a rolling release, neither of these are easy)

This is a widespread notion but I honestly don't get it...

If we were talking about some cryptic app that only exists in AUR I would be agreeing, but we're talking about Mesa here.

How's adding Kisak's (Stable) Mesa PPA in any way difficult on Ubuntu and derivates?

On Linux Mint (even though it's the anthitesys of rolling release, because it's always based on Ubuntu LTS with a bonus ~6 month delay) we have a GUI for adding PPAs (and even 3rd-party Debian repos) called "Software Sources". It's not out-of-the-box, but it's at least a go-here-paste-this-click-ok do-once-and-forget procedure, so not that hard at all, right?

As for kernels, Linux Mint has a GUI for kernel version management offering whatever is available on kernel.ubuntu.org HWE stack for the Ubuntu LTS version it's based on, and kernel updates also follow through the Update Manager. 3 clicks will move you over the newest branch available then normal updates will keep it at the last revision.

On Ubuntu itself this is AFAIK a bit less friendly, but there is UKUU (3rd-party app) to cover the GUI-based kernel management gap and this even supports vanilla kernel.org releases, branch auto-upgrades, etc. There are other similar-purpose apps too, and they work across Ubuntu derivates as well.

All of which should NOT be required for video card drivers.

Installing PPAs only works for Ubuntu based distributions, and will break the entire purpose of running an LTS release. As will installing unsupported kernels. In this case, generally speaking, the only valid 'stable' release would be Debian, as it does support the backports.

It isn't simply a notion. If you're coming from say Windows or mac (macs don't even let the users deal with drivers outside of random third party devices) and either your video driver is updated via Windows Update, or via downloading some installer from a website. Coming to Linux you are suddenly asked to enable third party package repositories to replace your kernel and 3d libraries? So yeah, neither nvidia nor amd are great. Intel, sadly, is probably the best supported. Hopefully that continues with the ARC cards. If it does, I may consider the loss of performance worth it.

Quoting: slaapliedjeIt isn't simply a notion. If you're coming from say Windows or mac (macs don't even let the users deal with drivers outside of random third party devices) and either your video driver is updated via Windows Update, or via downloading some installer from a website. Coming to Linux you are suddenly asked to enable third party package repositories to replace your kernel and 3d libraries?

Well, no. Only if you want something later and greater than the distro just naturally provides and updates. I personally have never messed with my AMD driver at all, and I'm on Mint. But my gaming isn't heavy, heaviest thing I ever play is Stellaris and it's not exactly new, so I have no need to worry about what's current.

Kisak is one of Valve's linux devs, working on upstream Mesa.

Having an LTS distro is *partially* uncaracterized by adding Kisak Mesa PPA... it does bring in a newer than officially curated component to the OS, but only that one and not the whole mass of core components that the LTS freezes when released. This limits the amount of issues derived from updating packages to a minimum, and makes it much easier to guess if the PPA is or isn't involved.

If that's the only PPA you need, you know graphics issues that arise my stem from it and that removing it and reversing Mesa to the default Ubuntu version is a useful test to fix graphics issues.

This does open the door to "PPA Hell" where a user adds many PPAs and a few of them provide an overlapping selection of packages with conflicting version requirements in that overlap. Reliable PPA sources are careful to avoid putting too much stuff in a single PPA to prevent such overlaps, but there are some examples otherwise.

However most often than not a PPA breaks the system just because it pushed a buggy new version of a package (Oibaf, I'm looking at you!) and this happens to rolling-release distros too.


Also keep in mind that for gaming on Ubuntu LTS, Mesa is the only PPA that Valve themselves recommend going for a newer than default version, and then only if you want to enjoy the latest features they contributed upstream.

It's not a hard requirement anymore, not like when Valve first started getting their hands dirty with the linux graphics stack. Most of their essential contribuitions are already contributed upstream to Mesa and Kernel devs AND pulled downstream into Ubuntu LTS too.


If you think this is too much, it's ok... that's why I like the fact that we have so many good distros! But IMHO it doesn't really make our lives difficult on non-rolling distros if we need a couple things that aren't there by default.

ps: I'm a casual gamer using Linux Mint without any PPA and Steam and Proton work just fine here. I haven't even moved from Linux Mint 20.x to 21, so my distro is based off Ubuntu 20.04, not 22.04, and that's still enough to get things going just fine here.

I also experimentally enabled Kisak PPA on one of my machines and left it there, with Mint's auto-update feature enabled, and the PPA updates are auto-applied without issue (it's been ~1 year since the experiment started).

I don't recommend Oibaf, it's been the source of several threads on the "Steam on Linux" discussion forum on Steam. Kisak on the other hand has almost never (... ... ... maybe actually never?!!) been pinpointed as the source of an issue there.

Oibaf does make it clear that his PPA is on the more experimental side, and Kisak does make it clear his is more on the safe side, so all is as it should.

Quoting: Purple Library Guy

Quoting: slaapliedjeIt isn't simply a notion. If you're coming from say Windows or mac (macs don't even let the users deal with drivers outside of random third party devices) and either your video driver is updated via Windows Update, or via downloading some installer from a website. Coming to Linux you are suddenly asked to enable third party package repositories to replace your kernel and 3d libraries?

Well, no. Only if you want something later and greater than the distro just naturally provides and updates. I personally have never messed with my AMD driver at all, and I'm on Mint. But my gaming isn't heavy, heaviest thing I ever play is Stellaris and it's not exactly new, so I have no need to worry about what's current.

This is really only needed for newer cards. Though there for sure are times when you also would need to do this for newer games. I blame this on the whole industry abd the fact we still have a weird case where new games use new features that are available on older hardware, but only with newer drivers. I tend to think it was one of the main issues with OpenGL that they still didn't really fix with Vulkan.

Let me also take one thing off my chest:

Downloading a driver installer .exe from the GPU manufacturer website is a HORRIBLE user experience compared to adding a PPA, even if the driver control panel warns you of a newer version and offers the correct download url (instead of the more common situation where the entire thing is manual).

I should know... I had SERIOUS issues with windows drivers including but not limited to running driver updates for a Sapphire HD 7770 (AMD) GPU on Win7. Updates didn't apply cleanly over older versions of the driver, so you had to uninstall the previous driver first... and the uninstaller didn't really remove everything so you had to use 3rd-party cleaner apps... and those also didn't catch 100% of the mess so at some point I discovered that Microsoft wasn't satisfied with the Windows Registry and had created ANOTHER even more cryptic repository for system configs (which I don't even remember the name anymore... IIRC it wasn't group policies but maybe) and AMD thought it was a good idea to use that.

Anyway, this was such a poor user experience that moving to linux and wrestling with Radeon (the legacy opensource driver) was a relief and this was before Valve threw money at all our problems.

Adding a PPA then using the Update Manager to check, fetch and apply updates for the entire OS plus all apps is waaaaay better than installer.exe from website and even better than Windows Updates sluggish downloads, cumulative updates ordering issues, consecutive reboots, unreliability, haphazard 3rd-party GUIs for each 3rd-party app update, etc.

This version is not available for Ubuntu yet...

Here is one more bit about "fetch driver installer from manufacturer website"

We do have that option on Linux if the manufacturer goes through the trouble of making such an installer.

Nvidia does, yet here is what they say about it:
https://www.nvidia.com/download/driverResults.aspx/193764/en-us/

QuoteNote that many Linux distributions provide their own packages of the NVIDIA Linux Graphics Driver in the distribution's native package management format. This may interact better with the rest of your distribution's framework, and you may want to use this rather than NVIDIA's official package.

AMD offers their proprietary linux driver this way too (but it's worse than Mesa for gaming).


Indeed the most recommended Nvidia driver PPA for Ubuntu (ppa:graphics-drivers/ppa) is still offering versions up to 515, not including 520.
https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa

But be careful because the newest major version number currently on offer by Nvidia iis usually the testing branch, while the stable branch uses a smaller major version number... and they even have a 3rd branch just for Vulkan new stuff.

520 is showing only on the "New Feature Branch" here:
https://www.nvidia.com/Download/index.aspx?lang=en-us#

QuoteLLB / SLB
Production Branch drivers provide ISV certification and optimal stability and performance for Unix customers. This driver is most commonly deployed at enterprises, providing support for the sustained bug fix and security updates commonly required.

New Feature Branch drivers provide early adopters and bleeding edge developers access to the latest driver features before they are integrated into the Production Branches

Last edited by Marlock on 13 October 2022 at 10:33 am UTC

Quoting: Purple Library Guy

Quoting: rcrit

Quoting: MarlockThis is a widespread notion but I honestly don't get it...

If we were talking about some cryptic app that only exists in AUR I would be agreeing, but we're talking about Mesa here.

How's adding Kisak's (Stable) Mesa PPA in any way difficult on Ubuntu and derivates?

What about for non-Ubuntu and derivatives?

So, you're saying it might be true of distros that are neither rolling release and/or Arch derivatives, nor Ubuntu and derivatives?
Are there distros that are intended for ease of use that also don't fit either of those baskets?

Yes, OpenSuSE (not Thumbleweed, though if you wanted a Rolling release, it could also fit the bill), and though mostly not considered as one (due to fame and some past facts, rather than actual, current facts), Fedora and its derivtives (though I've found these to be less polished than vanilla Fedora, so I tend to install and bend it to my will).

At any rate, I've been running nVidia on Linux for a LOOOOONG time now (yes 20 years, yay!), and certainly can relate to much of the flak it gets, but seriously, for all that past time, any other provider performed subpar, until very recently, by comparison (in the realm of the last 5 to 6 years), when AMD really started to perform well on Linux.

I bought a new nvidia graphics card in 2022 for use exclussively with Linux. I have seldom seen what many people complain about nvidia from the user's perspective. From a [Linux and infrastructure] developer's perspective, I know it is hell working with them. Maybe I've grown used to what to expect from using it, yes I have been annoyed recently by some driver quirkness that was not present in my past card or was not apparent in it, yes AMD (and Intel for that matter) offer a MUCH smoother desktop use, and I am fine with that as well.

It is good to know they've addressed some issues with this release, hopefully they keep on their track of going in the right direction with opening more of their graphics stack (alas I doubt it knowing they share as much as 95% of their code with the Windows drivers, or so they said a few years ago), which will in the end benefit us all.

after upgrading to 520.56.06 (from 515.76), the game Valheim I was just playing minutes before, became unplayable

because I'm running Fedora Silverblue I could just rollback the commit to the previous driver version, and was playable again

That's due to Silverblue's read-only system core + writeable system layer, right? (not sure the proper name for this)

AFAIK this could be used with a non-rolling distro, but I'm not sure how well that would work. Do you have any insight?

Also there are ways to roll-back and pin a package to a specific version until a bug is fixed, then unpin to resume normal updates, in both rolling and non-rolling distros. I gather that Silverblue has a potential advantage here because it's not just replacing a new component for an old one, but actually reverting to the exact way it was before the problematic update hit... in most cases the results would be similar, but there are probably exceptions where this is prefered... and I imagine the classic pinning operation is also available to Silverblue if prefered.


Last edited by Marlock on 24 October 2022 at 2:28 am UTC