Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone with no article paywalls. Just good, fresh content! Alternatively, you can donate through PayPal, Liberapay or Buy us a Coffee. You can also buy games using our partner links for GOG and Humble Store.

NVIDIA 495.44 stable driver is out for Linux, adds in GBM API support

By - | Views: 20,924

Following on from the NVIDIA Beta 495.29.05 earlier this month, today NVIDIA has a fresh 495.44 stable driver release that builds upon it with some additional extras. This is the big one for Wayland fans, since it now works with the GBM API.

With this API now hooked up, it should mean a better Wayland experience and it's something that the KDE Plasma team are already working on supporting too.

You will also find in this release an indicator (on supported desktops) for showing Resizable BAR and the minimum Kernel version got bumped from 2.6.32 to 3.10. Additionally these new extensions are supported:

There's also a healthy dose of bug fixes and other changes noted below:

  • Fixed a bug that could cause the X server to crash when starting a new server generation on PRIME configurations.
  • Removed support for NvIFROpenGL. This functionality was deprecated in the 470.xx driver release.
  • Removed libnvidia-cbl.so from the driver package. This functionality is now provided by other driver libraries.
  • Updated nvidia.ko to load even if no supported NVIDIA GPUs are present when an NVIDIA NVSwitch device is detected in the system. Previously, nvidia.ko would fail to load into the kernel if no supported GPUs were present.
  • Fixed a bug in the Vulkan driver where unused input attributes to a vertex shader would corrupt the interpolation qualifiers for the shader.
  • Fixed a bug in the Vulkan driver where individual components of barycentric inputs could not be read.
  • Fixed a bug where VK_NVX_binary_import was advertised as supported on unsupported platforms. This caused calls to vkCreateDevice to fail if applications attempted to enable VK_NVX_binary_import on such platforms.
  • Added a new command line option, "--no-peermem", to nvidia-installer.Selecting this option prevents the installation of the nvidia-peermem kernel module.
  • Fixed a regression which prevented DisplayPort and HDMI 2.1 variable refresh rate (VRR) G-SYNC Compatible monitors from functioning correctly in variable refresh rate mode, resulting in issues such as flickering.
  • Fixed a bug that can cause a kernel crash in SLI Mosaic configurations.

Since this is a stable driver release all users should be okay to upgrade.

Article taken from GamingOnLinux.com.
29 Likes
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG and Humble Store. See more here.
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.
See more from me
43 comments
Page: «4/5»
  Go to:

3zekiel 27 Oct
  • Supporter
Quoting: omer666
Quoting: 3zekielThe situation indeed isn't as simple as "Nvidia evil vs good guy everyone else". Nvidia based its solution on a standard existing somewhere else (that did not pan out as expected) so they did not make a revolution in their own little world.
Actually Nvidia didn't even bother discussing the matter when the other vendors were making the choice, and decided to go for EGLStream all alone.

Then, they wanted to discuss how EGLStreams was supposed to be technically better, which lasted for quite a few years.

Then, they wanted to develop a new API, they wrote some code and put it on github, and is never went any further.

Then, when RedHat pushed for EGLStream compatibility in Fedora, it was mainlined in mutter but Nvidia was still not compatible with XWayland.

Fast forward 2021, Nvidia patches XWayland, only to give up a few months later and make their driver work with GBM.

Literally, they've been messing around for 5 years for nothing. The only visible effect of this is the harm they made to Wayland adoption and innovation on Linux at large.

Some sources:
Nvidia presenting EGLStreams in 2014
Nvidia wanting a new API
Nivida's Unix Memory Allocator on Github (last updated 4 years ago)

For the start, choosing to go EGLStream despite other vendors is indeed true.
That being said, it was done at a time where wayland was non existant (we need to remember that it is still barely usable in some significant cases, on AMD you can not share your screen with google meet as an example...).
I am not saying they did a good/nice choice. But moderating the idea that they would be "evil".

As for whether they messed around for 5 years, they did propose the better API, but as far as I saw, no one really came and discussed either ... Or maybe it happened behind curtains. Once again reality is a bit more gray than black or white ... And once again, of course, they acted a bit like divas who expect all attention even when coming late to the party.

Of course, at the very end, the conclusion is that technically their solution does not work as it should, but I was more saying it was not as easy to detemine at the begining. And as always, once a project has taken a certain path, it is often hard to backtract. You need to have the clarity to take a break and look back.

My opinion is that they just had some technical bad choice and perseverated by lack of clarity more than by evil-ness.
BielFPs 27 Oct
Quoting: slaapliedjeOn FreeBSD 13, if you install it on a system with an Nvidia card, it still defaults to Wayland, but it just crashes when you try to log into KDE (can't remember if Gnome did it too), you have to switch to Xorg then it works fine. Weirdest thing as I'd think sddm wouldn't work as well, but it works fine..
Didn't knew that BSD had wayland too, I remember that the unfortunately side of Wayland was being linux exclusive, nice to know
x_wing 27 Oct
Quoting: 3zekielAs for whether they messed around for 5 years, they did propose the better API, but as far as I saw, no one really came and discussed either ... Or maybe it happened behind curtains. Once again reality is a bit more gray than black or white ... And once again, of course, they acted a bit like divas who expect all attention even when coming late to the party.

Of course, at the very end, the conclusion is that technically their solution does not work as it should, but I was more saying it was not as easy to detemine at the begining. And as always, once a project has taken a certain path, it is often hard to backtract. You need to have the clarity to take a break and look back.

My opinion is that they just had some technical bad choice and perseverated by lack of clarity more than by evil-ness.

This is not only about technical decisions, this is more of an attitude problem with our community. You cannot expect that the community would drop their work on GBM to move to your new "standard" because you failed with your personal endeavor with EGLStreams.

There is no gray area, their strategy from the beginning was to use a solution that adapted well to their driver needs not caring on anyone else. And as I said, this is not an isolated case, it is just the way they do everything: https://www.phoronix.com/scan.php?page=news_item&px=Nouveau-XDC2017

There is no way we can soft their behavior of all this years. They are simply bully jerks...
3zekiel 27 Oct
  • Supporter
Quoting: x_wingThis is not only about technical decisions, this is more of an attitude problem with our community. You cannot expect that the community would drop their work on GBM to move to your new "standard" because you failed with your personal endeavor with EGLStreams.

The attitude issue I agree. Sadly, they are like too many hw vendors who tend to enjoy working behind closed doors and behave like control freaks.

Their last year has however been much more fruitful, with egl wayland and co they seem to work much more in the open. They seem to communicate much more overall, and they directly supported DLSS in proton. I mean, they did not do it out of goodness of their heart (no company does), but it does seem like they are softening to us... Now, time will tell. I still wait that "Big open source announcement" they were supposed to do months and months ago.

I mean, technically speaking open sourcing they freaking driver is still what makes the most sense... Maybe at some point they will realize it, just like they finally did for GBM. One can always dream (and meanwhile buy GPUs from more open source friendly vendors, when they are finally available anyway:P )
Quoting: Comandante ÑoñardoWhat about 470.82.00?
Anyway, none of two are available for Ubuntu 20.04 LTS yet.
Do you know if the 495 driver is avaliable yet on Ubuntu?
slaapliedje 27 Oct
View PC info
  • Supporter Plus
Quoting: BielFPs
Quoting: slaapliedjeOn FreeBSD 13, if you install it on a system with an Nvidia card, it still defaults to Wayland, but it just crashes when you try to log into KDE (can't remember if Gnome did it too), you have to switch to Xorg then it works fine. Weirdest thing as I'd think sddm wouldn't work as well, but it works fine..
Didn't knew that BSD had wayland too, I remember that the unfortunately side of Wayland was being linux exclusive, nice to know
You know, I had heard people insist that Gnome was also becoming Linux only because of its tie to systemd, but FreeBSD still has an (almost) current version of Gnome.

I kept wanting to get it set up on some 2008/2009 macbooks someone gave me, but I did not have much luck.
shanedav4 29 Oct
It's still not an install an go to get it working. You have to compile and install a couple dev version libraries to get it working. One is Xwayland. Forget about installing it on anything but the most bleeding edge rolling release distros. I would say it is still very much beta.
Redface 29 Oct
Quoting: Brandonmccoub2
Quoting: Comandante ÑoñardoWhat about 470.82.00?
Anyway, none of two are available for Ubuntu 20.04 LTS yet.
Do you know if the 495 driver is avaliable yet on Ubuntu?

Both 470.82.00 and 495.44 are in proposed for all supported releases from 18.04 up and the development for 22.04, see https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-470/+bug/1948025

There is always a bugreport tracking the new driver https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-470/+bug/1948025 for 495, I tend to find them on https://people.canonical.com/~ubuntu-archive/pending-sru.html searching for nvidia or whatever I am looking for.

Soon they will come as normal updates unless there are problems delaying that. If you want to try them from proposed read https://wiki.ubuntu.com/Testing/EnableProposed , do not just enable proposed and get everything from there.

I just installed 495 on 21.10 and seems to be ok, I tried Stellaris 64bit, Shadowrun 32bit and a youtube video
Still on xorg, I am going to try with wayland now
Torqachu 31 Oct
not knowing where to write...
For kepler card users on archlinux/derivate the 470 drivers have appeared in aur.
who wants to be a guinea pig?
Epic Games Store (Lutris) won't open for me on 495, going back to 470 it works fine.
While you're here, please consider supporting GamingOnLinux on:

Patreon, Liberapay or PayPal Donation.

This ensures all of our main content remains totally free for everyone with no article paywalls. We also don't have tons of adverts, there's also no tracking and we respect your privacy. Just 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!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.