Support us on Patreon
PayPalFollowing on from the 440.26 beta released last month, NVIDIA have today added a few more changes to it and pushed it out as a stable driver update with version 440.31.
It's a mixture of things big and small in this release. It adds in VP9 decode support to the NVIDIA VDPAU driver, parallel GLSL shader linking has been enabled by default, support for HDMI 2.1 variable refresh rate (VRR) with G-SYNC Compatible monitors and a supported GPU, HardDPMS enabled by default, support for newer multi-GPU rendering extensions and more.
As for bug fixes and other improvements: they solved issues when running applications using GLX indirect rendering, a fix preventing the NVIDIA kernel modules from building when your system isn't in English, kernel module building issues with the 5.4 Linux kernels, a confirmation box will now show when you try to quit nvidia-settings with unsaved changes and so on.
Also in this release are some fixes for DXVK, with Saints Row IV and Saints Row: The Third being mentioned that saw some kind of corruption which should now be solved. Another one that should hopefully help DXVK, is that it will fall back to system memory when video memory is full, they said it should help to fix "Xid 13 and Xid 31 cases in Vulkan applications" (not an issue limited to DXVK though).
This driver update also properly adds support for the new GeForce GTX 1660 SUPER.
You can find all the details on it here. Note: Rather than download it directly, it's usually better to wait for your distribution to package it so you don't break anything trying to manually install it.
Additionally, a new Vulkan Beta Driver release went up today with 435.27.03. It comes with the following changes:
Article taken from GamingOnLinux.com.
- New:
- Fixes:
- Improved behavior in low-memory situations
- Fixed graphical corruption in Vulkan game F12017
- Various minor performance improvements
- Improved Vulkan HDR support for multi-device configurations
benjamimgois Nov 5, 2019
Quoting: TheRiddickWaiting on POP_OS to update them, it seems they operate very slowly and is starting to make me angry for trying pop_os because I can't test beta nvidia drivers and their stable release updates are slow. Same reason why I hated Manjaro really. My next DISTRO will be pure arch, maybe with a easy to use installer.
On Manjaro/Arch Linux is very easy to update to the latest drivers, just add the Chaotic-AUR and they will be delivered to your package manager.
https://lonewolf.pedrohlc.com/chaotic-aur/
To install the beta-vulkan-driver look for the package "nvidia-dev-dkms-tkg"
Quoting: benjamimgoisOn Manjaro/Arch Linux is very easy to update to the latest drivers, just add the Chaotic-AUR and they will be delivered to your package manager.
And I thought Debian Experimental was a daunting name... :D
TheRiddick Nov 6, 2019
Quoting: benjamimgoishttps://lonewolf.pedrohlc.com/chaotic-aur/
How is this compatible with Manjaro which has a special driver configuration?
QuoteThe X driver will now create a fallback pathname UNIX domain socket in the directory specified by the "SidebandSocketPath" option, or /var/run by default, which will be used by other NVIDIA driver components if they are unable to connect to the default abstract socket.This fixes a bug where graphics applications run within a network namespace (which prevents the use of abstract sockets) were unable to take advantage of some driver features, such as G-Sync.If you run Steam and/or games inside a network namespace (for example, using Docker), G-Sync wouldn't work before. I use such namespaces to allow Steam (and games) to connect directly while for everything else I use a VPN. It's a pretty unusual setup but I need it to work around censorship and still have regional prices on Steam (that are usually -70% from the base dollar price) so Steam has to see my real IP, and also have low ping in multiplayer games. It's the most robust solution that I found as all I need is to run Steam in that namespace and everything it spawns stays in the same namespace so no need to mess with iptables, routes, ports and such. The programs only see one network interface (a virtual ethernet "pipe" that bridges the namespaces) and one default route (my router), they're not even aware of the VPN's tun0 interface and can't use it.
I reported this bug before and it took about a year to fix but eventually it's here and it works. Arthur Huillet found me on IRC (that was a big surprise) and we discussed the issue in details. I used a kernel hack before that basically turns off anonymous UNIX domain sockets isolation (they're not accessible across namespaces) by removing a couple of lines, no sideffects that I'm aware of but I know it's not a good thing. Now it's obsolete and I can use a regular kernel build. This NVIDIA's socket has a long weird and random name, it's not documented anywhere and NVIDIA seem to call it "sideband". I have to admit, if the driver were opensource I could've fixed it myself long ago probably...
I see it was built for the Focal archive, but that's it.
Comandante Ñoñardo Dec 2, 2019
Quoting: MamboStill nothing on the PPA front.
I see it was built for the Focal archive, but that's it.
And there is a NEW driver for Linux, the 440.36, adding support for the new 1650 SUPER.
Comandante Ñoñardo Dec 4, 2019
See more from me