Two new driver releases are now available for desktop Linux users with NVIDIA 515.76 and Mesa 22.2 for AMD / Intel.
With the NVIDIA release being quite a small one here's what's new:
- Turing and later: fixed possible excessive GPU power draw on an idle X11 or Wayland desktop when driving high resolutions or refresh rates.
- Fixed a bug that caused the Xorg server to crash if an NvFBC capture session is started while video memory is full.
As for the new Mesa release, there's been no official announcement or changelog despite the release happening yesterday which our pal at Phoronix spotted and they noted some of these improvements available in Mesa 22.2:
- Better Intel Arc support.
- Intel Ray Tracing performance improvements.
- Intel Vulkan improvements for VKD3D-Proton.
- Work towards AMD RDNA3 support.
- Nouveau starting work towards supporting NVIDIA RTX 3xxx series.
- And various other bug fixes and improvements.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
mr-victory Sep 21, 2022
Crash on IBT enabled systems still not fixed😡
https://github.com/NVIDIA/open-gpu-kernel-modules/issues/256
https://github.com/NVIDIA/open-gpu-kernel-modules/issues/256
0 Likes
Ah, nvidia drivers on linux, the thing that people use to train all those AI models to generate random images and text! Oh, and don't forget about the crypto scams!
Wait, you can actually play games? Using an Nvidia card? On a Linux Desktop? I thought that was AMD-only
Ok, ok, I'll stop. I'm just a bit skeptical about their priorities, is all
Wait, you can actually play games? Using an Nvidia card? On a Linux Desktop? I thought that was AMD-only
Ok, ok, I'll stop. I'm just a bit skeptical about their priorities, is all
2 Likes, Who?
mr-victory Sep 21, 2022
Quoting: setzer22Wait, you can actually play games? Using an Nvidia card? On a Linux Desktop? I thought that was AMD-onlyI play on Optimus laptop, GamingOnLinuxWithNvidia isn't a myth ;)
0 Likes
Quoting: setzer22Ok, ok, I'll stop. I'm just a bit skeptical about their priorities, is all
Because AMD priorities are to serve your needs?
0 Likes
Quoting: EhvisQuoting: setzer22Ok, ok, I'll stop. I'm just a bit skeptical about their priorities, is all
Because AMD priorities are to serve your needs?
Actions speak far louder than words, and AMD has committed a lot of code and continues to do so.
0 Likes
Quoting: TrainDocQuoting: EhvisQuoting: setzer22Ok, ok, I'll stop. I'm just a bit skeptical about their priorities, is all
Because AMD priorities are to serve your needs?
Actions speak far louder than words, and AMD has committed a lot of code and continues to do so.
And nvidia has supported Linux with drivers for 20 years. Doesn't matter. Both are large companies with big shareholders. Only one things counts. Today that path may benefit us, tomorrow it may be the opposite. It's a means to an end, nothing more.
1 Likes, Who?
It's not that simple... Nvidia was king of the hill until recently because their paid developers do good work on their proprietary linux drivers, and AMD just couldn't afford so much in-house work on theirs (remember AMD as a whole has hanged by a thread after 2 consecutive cpus and some gpus performed worse or eat more power than their Intel CPU and Nvidia GPU competition).
Then AMD had a hardware comeback with Ryzen and their newer gpu gens, which gave them a little more room to breath in the financial aspect... and meanwhile they opensourced their linux gpu drivers (which took years of hard effort and a new driver, with severe growing pains to get it up to speed)...
...and then 3rd-parties (mainly Valve) got interested in AMD GPUs (because they're now quite capable for their price and power consumption) and their drivers (because they are opensource)...
...and then everything changed!
AMD still has not as much money to put into linux driver development as Nvidia, but any other interested party can put their hands on the driver and help (not just pay AMD some commissioned work, actually look at the code from a fresh perspective and help!)
If you said 5 years ago that from a practical perspective a proprietary driver can be just as good as an opensource driver or better, you'd be mostly right. Now not so much... openess paid off, and AMD has successfully leveraged the rest of the world to make their driver get better faster than their own money could achieve, gaining the upper hand in multiple (un)expected ways and winning the preference of several customers due to those.
Nvidia's move towards an official linux opensource gpu driver (beyond their ARM boards and beyond the quixotesque 3rd-party noveau mesa driver efforts) is IMHO a belated admission that they took the wrong turn over these years and that they know they are at risk of falling behind.
They could just throw even more money at the problem and maybe keep up... but opensourcing just brings more bang for buck than that and keeping their old strategy unchanged would cost them a lot.
Also from a user perspective, there practical negative consequences to dealing with a proprietary driver. Eg: you can't just grab a new kernel and expect their driver to work. The linux kernel APIs for user apps are rock solid stable, but the internal ABI calls between kernel pieces can change pretty quickly. If a driver is part of the mainlined kernel codebase, anyone proposing changes to these internal calls needs to take care of the other parts of the codebase that use it. If the driver is outside that codebase, the driver devs need to do the work themselves... and an old driver needs to be carefully replaced (before rebooting to the new kernel or else it might just crash at boot trying to use the old ABI over a new kernel).
There are also integration issues with linux features but AFAIK that's more due to Nvidia being stubborn and/or not being convincing enough about why doing things their way would be better (hint: their new drivers are meeting linux halfway after being stuck like a mule for ages and earning "the finger")
Last edited by Marlock on 21 September 2022 at 11:52 pm UTC
Then AMD had a hardware comeback with Ryzen and their newer gpu gens, which gave them a little more room to breath in the financial aspect... and meanwhile they opensourced their linux gpu drivers (which took years of hard effort and a new driver, with severe growing pains to get it up to speed)...
...and then 3rd-parties (mainly Valve) got interested in AMD GPUs (because they're now quite capable for their price and power consumption) and their drivers (because they are opensource)...
...and then everything changed!
AMD still has not as much money to put into linux driver development as Nvidia, but any other interested party can put their hands on the driver and help (not just pay AMD some commissioned work, actually look at the code from a fresh perspective and help!)
If you said 5 years ago that from a practical perspective a proprietary driver can be just as good as an opensource driver or better, you'd be mostly right. Now not so much... openess paid off, and AMD has successfully leveraged the rest of the world to make their driver get better faster than their own money could achieve, gaining the upper hand in multiple (un)expected ways and winning the preference of several customers due to those.
Nvidia's move towards an official linux opensource gpu driver (beyond their ARM boards and beyond the quixotesque 3rd-party noveau mesa driver efforts) is IMHO a belated admission that they took the wrong turn over these years and that they know they are at risk of falling behind.
They could just throw even more money at the problem and maybe keep up... but opensourcing just brings more bang for buck than that and keeping their old strategy unchanged would cost them a lot.
Also from a user perspective, there practical negative consequences to dealing with a proprietary driver. Eg: you can't just grab a new kernel and expect their driver to work. The linux kernel APIs for user apps are rock solid stable, but the internal ABI calls between kernel pieces can change pretty quickly. If a driver is part of the mainlined kernel codebase, anyone proposing changes to these internal calls needs to take care of the other parts of the codebase that use it. If the driver is outside that codebase, the driver devs need to do the work themselves... and an old driver needs to be carefully replaced (before rebooting to the new kernel or else it might just crash at boot trying to use the old ABI over a new kernel).
There are also integration issues with linux features but AFAIK that's more due to Nvidia being stubborn and/or not being convincing enough about why doing things their way would be better (hint: their new drivers are meeting linux halfway after being stuck like a mule for ages and earning "the finger")
Last edited by Marlock on 21 September 2022 at 11:52 pm UTC
2 Likes, Who?
What's best: AMD Proprietary drivers or up-to-date Mesa drivers?
0 Likes
mr-victory Sep 22, 2022
Quoting: AbreuWhat's best: AMD Proprietary drivers or up-to-date Mesa drivers?AFAIK you use Mesa for gaming because it is better and install amdgpu-pro alongside Mesa for OpenCL/compute stuff because Mesa doesn't support them.
0 Likes
Patreon
PayPal
See more from me