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.

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
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly checked 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
The comments on this article are closed.
42 comments
Page: «3/5»
  Go to:

Comandante Ñoñardo Oct 27, 2021
What about 470.82.00?
Anyway, none of two are available for Ubuntu 20.04 LTS yet.
x_wing Oct 27, 2021
Quoting: scaineI have no idea what you're talking about here. Nvidia blocked something... how? Or is this tired old "Mir" argument, in which I'm sick of hearing it, since, after all, competing standards literally defines what Linux is.

No idea how you block open source alternatives though. Is this about that Microsoft-funded company that brought lawsuits to big Linux houses with bogus patents? I forget their name.

Yeah, sorry. No idea what this is about.

Seems that you never read the story of Nouveau driver in all this years, don't you? If you know of an alternative, let us know, as in the current scenario many Nvidia users won't be able to use wayland unless they upgrade their hardware.

Lets stop playing dumb. Nvidia pushed for EGLStream against GBM for many years. They only changed their mind after completely failing to make it work. Simple as that.
scaine Oct 27, 2021
View PC info
  • Contributing Editor
  • Mega Supporter
Quoting: x_wing
Quoting: scaineI have no idea what you're talking about here. Nvidia blocked something... how? Or is this tired old "Mir" argument, in which I'm sick of hearing it, since, after all, competing standards literally defines what Linux is.

No idea how you block open source alternatives though. Is this about that Microsoft-funded company that brought lawsuits to big Linux houses with bogus patents? I forget their name.

Yeah, sorry. No idea what this is about.

Seems that you never read the story of Nouveau driver in all this years, don't you? If you know of an alternative, let us know, as in the current scenario many Nvidia users won't be able to use wayland unless they upgrade their hardware.

Lets stop playing dumb. Nvidia pushed for EGLStream against GBM for many years. They only changed their mind after completely failing to make it work. Simple as that.

I genuinely wasn't playing dumb - I hadn't a single clue to what you were referring (which is why I guessed three different scenarios). But sure, you meant the fact that Nvidia refused to implement a technology that Wayland relied on. That's... I mean, sure, that's really annoying. But maybe there's some responsibility on Wayland for relying on technology that wasn't present in all drivers? Actually, thinking back, wasn't the unrealistic position of Wayland, 8 years ago, the very reason that Canonical created Mir? One of the biggest reasons anyway, I think.

Let's just be happy that Nvidia have finally come around to supporting this requirement in their proprietary driver. More than ever, this whole story shows why open source drivers are so important. And tbh, I didn't really understand that until I went AMD a couple of years ago.


Last edited by scaine on 27 October 2021 at 10:38 am UTC
3zekiel Oct 27, 2021
Quoting: scaine
Quoting: x_wing
Quoting: scaineI have no idea what you're talking about here. Nvidia blocked something... how? Or is this tired old "Mir" argument, in which I'm sick of hearing it, since, after all, competing standards literally defines what Linux is.

No idea how you block open source alternatives though. Is this about that Microsoft-funded company that brought lawsuits to big Linux houses with bogus patents? I forget their name.

Yeah, sorry. No idea what this is about.

Seems that you never read the story of Nouveau driver in all this years, don't you? If you know of an alternative, let us know, as in the current scenario many Nvidia users won't be able to use wayland unless they upgrade their hardware.

Lets stop playing dumb. Nvidia pushed for EGLStream against GBM for many years. They only changed their mind after completely failing to make it work. Simple as that.

I genuinely wasn't playing dumb - I hadn't a single clue to what you were referring (which is why I guessed three different scenarios). But sure, you meant the fact that Nvidia refused to implement a technology that Wayland relied on. That's... I mean, sure, that's really annoying. But maybe there's some responsibility on Wayland for relying on technology that wasn't present in all drivers? Actually, thinking back, wasn't the unrealistic position of Wayland, 8 years ago, the very reason that Canonical created Mir? One of the biggest reasons anyway, I think.

Let's just be happy that Nvidia have finally come around to supporting this requirement in their proprietary driver. More than ever, this whole story shows why open source drivers are so important. And tbh, I didn't really understand that until I went AMD a couple of years ago.


The 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.
Once they saw it did not work for others, they proposed to work together on a standard that would be better than both current implementations.... But no one really worked with them. They waited a while and finally fell back on GBM.
Now, were they wrong fro EGLStream at the very beginning? that's a complicated thing to say. It's easy to say now that it lacks some features and co, but at the time nothing was working on wayland, so very hard to evaluate from their perspective.
Also, they did try to create a better standard with the community, but only got the cold shoulder. Which to be fair might be due to them being perceived as divas and leeches. Which might not be really justified, but it can be understood from other driver dev perspective.

As for the issue of legacy cards, kepler is real old, dating from May 30th, 2013 for the gtx 770. Having support forever on hw is not realistic, and is never happening. It only lasts as long as it makes sense commercially. Also, it is not as if they were flat out dropped in the mud, they only will not get wayland support. X will still be there for quite a few years before it gets fully dropped and thoses cards become e-waste. By the time, they will be way north of 10 years old ...
aufkrawall Oct 27, 2021
Yet 780 Ti (fall 2013 650€) is still ~RX 480 performance (at least when VRAM pressure or explicit APIs don't kill it) and old hardware is supported ~forever in Mesa and kernel. It's unfortunate.
wolfyrion Oct 27, 2021
Wayland has a lot of problems and even with AMD Graphic cards I am not able to use it.

If you have one monitor is ok to use Wayland but if you have 4x monitors then is a total chaos.

For example You are not able to set a Monitor as your primary monitor.
omer666 Oct 27, 2021
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)
senpaigamer123 Oct 27, 2021
literally revived my old 780 last night by baking it. so the dropped support is kind of disappointing if I plan to use it for anything.
slaapliedje Oct 27, 2021
Quoting: BielFPsAnd I would like to welcome the Nvidia users friends to the wayland side of the force

I hope now the Linux Mint devs can stop pretending that Wayland is not a thing.
On 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..
3zekiel Oct 27, 2021
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.
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.
Buy Games
Buy games with our affiliate / partner links: