Check out our Monthly Survey Page to see what our users are running.
We do often include affiliate links to earn us some pennies. See more here.

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

By - | Views: 31,126

NVIDIA has today released driver version 520.56.06, adding support for NVIDIA RTX 40 series and adding a bunch of new features and fixes for Linux gamers.

New features:

  • Implemented support for over-the-air updates in the Proton and Wine NVIDIA NGX build. This feature is disabled by default and can be enabled by setting the "PROTON_ENABLE_NGX_UPDATER" environment variable to a value of "1".
  • Updated the Vulkan driver so that the following extensions no longer depend on nvidia-uvm.ko being loaded at runtime:
    • VK_KHR_acceleration_structure
    • VK_KHR_deferred_host_operations
    • VK_KHR_ray_query
    • VK_KHR_ray_tracing_pipeline
    • VK_NV_cuda_kernel_launch
    • VK_NV_ray_tracing
    • VK_NV_ray_tracing_motion_blur
    • VK_NVX_binary_import
    • VK_NVX_image_view_handle

Updates:

  • Updated nvidia-installer to allow use of the "--add-this-kernel" feature by non-root users.
  • Updated nvidia-installer to display a more accurate progress bar when building the kernel modules.
  • Updated nvidia-installer to display a warning message if a Vulkan ICD loader is not detected.
  • Reworked nvidia-installer's support for DKMS: the kernel modules will now be optionally registered with DKMS after the installer has already built and installed them on its own. nvidia-installer will now register the kernel modules with DKMS by default when the dkms(8) utility is detected on the system.
  • Added a new CUDA Debugger implementation for Pascal and newer architectures as a part of the driver package: libcudadebugger.so (previously released separately as "CUDA GDB Developer Preview").

Fixes:

  • Fixed a bug in the Vulkan driver which could lead to corruption in geometry and tessellation control shaders.
  • Fixed a regression in 515.76 that caused blank screens and hangs when starting an X server on RTX 30 series GPUs in some configurations where the boot display is connected via HDMI.
  • Fixed a bug where Marvel's Spider-Man Remastered would sometimes crash with Xid 13 errors on Turing and later.

What are your thoughts on this update? Let us know in the comments.

In related news, in case you missed it, there's a new Mesa NVIDIA Vulkan driver in development.

Article taken from GamingOnLinux.com.
13 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
24 comments
Page: «2/3»
  Go to:

slaapliedje Oct 12, 2022
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.
Purple Library Guy Oct 12, 2022
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.
Marlock Oct 12, 2022
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.
slaapliedje Oct 13, 2022
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.
Marlock Oct 13, 2022
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.
Comandante Ñoñardo Oct 13, 2022
This version is not available for Ubuntu yet...
Marlock Oct 13, 2022
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
Thetargos Oct 15, 2022
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.
rscm Oct 23, 2022
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
Marlock Oct 24, 2022
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
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.