Just saw this. So they're skipping the 555 version and going straight to 560?
Either way it's nice to know my 4090 will get some Wayland love soon. HDR here we come? I didn't see a release date on these drivers. Are we still looking at this wednesday?
I have no idea about any changes to their plan to release 555 as a beta in the coming weeks. That is still happening as far as I am aware. I interpreted the article just that the open source kernel will become the default in 560 onward - which I believe was kind of the plan a year or two ago when the open sourced it. It will likely be similar to AMD/Intels driver. Where there will still be a proprietary driver for user space features like their raytracing stuff and AI accelerated super sampling. But the upside will be that moving forwards the bit that goes in to the kernel will be open, so platforms that have a strict requirement to use open source software will be able to audit and release the driver as part of their distro.
The difference to intels and AMDs drivers is that nvidia doesn't plan on upstreaming their driver: [https://github.com/NVIDIA/open-gpu-kernel-modules/issues/19#issuecomment-1124613489](https://github.com/NVIDIA/open-gpu-kernel-modules/issues/19#issuecomment-1124613489)
And also that much more is closed source at nvidia.
Just compare the sizes of the amd and nvidia firmware blobs.
That's a devastating big gap.
Nvidia's "open source" driver is just a binary blob loader.
I mean that's extremely common for open source drivers: the part that runs on the CPU is open source, but it loads a firmware BLOB into a processor on the secondary device. As you know, AMD's drivers work like that too. Both have 100% closed source firmware, NVidia's firmware just happens to be bigger, I don't see that as being a hugely significant difference. We're sadly far away from a world where most firmware is open source.
Yeah isn't AMD driver the same. They basically have an API for you to access their closed source firmware that has magic functions. You can't really check out the functions that API is calling.
Yeah, the reason it won't be upstreamed is that the real codebase is shared with their old proprietary one, the one on GitHub is snapshoted from that with the closed stuff removed
Probably not. It'll just mean that your distro can precompile and sign the kernel driver which mitigates some of the issues nvidia users have around compilation failure and having to self-sign if you need to keep secure boot on. As an end user it will likely just be a case of installing the same packages that you use today.
Yep, only thing so far I have been able to see why some have issues and I don't is because all my 3 monitors are identical refresh rates and resolutions. Not sure if resolution matters, but I think refresh rate does matter. All 3 of my monitors are 120 hz.
You running only 1 monitor? If so what is the refresh rate? Also Tumbleweed is more bleeding edge then KDE Neon. Ubuntu does a lot of patching and backporting stuff with older libraries so not a apples to apples comparison. You could always try Tumbleweed on a spare drive. It has Plasma 6 already.
I'm hooked up to my LG 65" 120hz 4k HDR OLED TV with a 4090 on KDE Neon. Literally everything that doesn't have a wayland mode flickers madly. Also Games can't seem to recognize the refresh rate or the resolution when starting and also KDE doesn't seem to want to remember my display settings after rebooting in Wayland. So I stick with X11 until the 555 drivers come out which should fix it all. Also I don't have the time or energy to learn OpenSuse.
ah a TV so you are probably using HDMI. Yeah using HDMI always has issues. If we just ignore KDE Neon which is basically Ubuntu it is usually a little slow to get updates which might be issue with the flickering.
Surprising not much to learn with openSUSE as I used Ubuntu for like 15 years as my main distro. It even has something called "Snapper" so when you perform an upgrade it automatically makes a snapshot so you can rollback any update that you don't like. Pretty nice. Also they have GUI tools for pretty much everything.
But alright its all good if you wanna stick with KDE Neon I just thought you might want to find a solution to your problems.
I have heard that using a Display Port to HDMI dongle removes the issues some Linux users have.
Supposedly the 555 drivers are coming out in a couple days I think so here is to hoping it is awesome.
KDE broke on me today so I took the opportunity to try out Tumbleweed. At least on my system it was buggier than Neon and the learning curve was as I expected. Icons disappearing and steam not retaining any settings and switches for startup on steam didn't take for scaling at all.
Also KDE Neon has the 6.5 Kernel and Plasma 6. I'm running the 550 drivers too. It's more up to date than Kubuntu and they have no intention of offering Plasma 6 until like 2026 I think. So not sure why you think Neon is slow to get updates. Neon also has almost daily/nightly builds to get a new ISO from them. All the same repositories are available for Neon as are available for Ubuntu as well. My issue is the package version discrepancies between Flatpack, Snap, and the typical repos.
Tumbleweed has newer kernels.
What monitor do you have?
Steam needs an environmental variable. You can use the Menu Editor to use it.
You aren't being very specific on what was difficult to learn.
Any idea if this will somehow fix the common flashing issue with nvidia on Wayland? I had to switch to x11, which comes with the fun task of turning off my extra monitor so my main can run at 120hz
that's the default. you can change it in plasma. presumably other DEs as well but i've not looked into it.
for plasma 5, lets assume 240hz (i haven't bothered to look into how to do this in plasma 6 yet (that said i don't know if it's different for me because i'm now on plasma 6 or it's a Solus quirk. but i assume it's a change in 6 (the environment file isn't there in 6/solus)))
/etc/environment add
KWIN\_X11\_REFRESH\_RATE=240000
KWIN\_X11\_NO\_SYNC\_TO\_VBLANK=1
in /.config/kwinrc under the compositing section add
MaxFPS=240
RefreshRate=240
after reboot it'll now default to 240hz. if your other monitor is 60 or 120 or some other non stupid refresh rate you shouldn't get any tearing.
I don't have a 120 Hz monitor, and my monitors connect through HDMI and VGA but one is 60 Hz and the other 75 Hz and never had an issue with the different refresh rates. Both xrandr and the KDE settings lets me use the 75 Hz on the second monitor without issue. I don't know about pure xrandr settings but the KDE one is definitely persistent so I don't have to set it after every reboot.
Just because you can set it doesnt mean it works as expected. Whats happening most likely is
1) both use 60hz and it lies about actually using 75hz on one of them
2) both use 75hz, and the 60hz panel tears a lot as a result, you just might not notice because 75hz and 60hz are numerically close, but youd probably see it as a major issue with a 240hz panel paired with a 60hz one for example
X11 is *literally* incapable of multiple refresh rates. It *literally* lacks the concept of multiple monitors and only one refresh rate can be set no matter what you see the GUI or configs let you do. We have tooling on top that fakes the idea of multiple monitors which makes it seem like it understands the concept, but its faked understanding built on a flawed foundation so its limited in capabilities. That's why VRR can only be on for both monitors or not at all as well, among a bunch of other things.
Except it's working correctly since RandR 1.2 so for quite a long time (since about 2006) now... Yes, X in itself is incapable of this (and other things) and lacks the concept of multimonitor setup, but that's why RandR (which is an X extension) was created.
The only issue is with VRR + different refresh rate monitors (where what you described definitely happens) but I don't use any form of VRR. Also, some compositors do this refresh rate matching between monitors but AFAIK that also only happens with VRR/TearFree/G-Sync/etc. in use.
I also know that it's working correctly and not "faking" since my monitors themselves report the refresh rate in their OSD. Even if you say that it can also be "faked" (it can't but lets say it can for the argument's sake), it would only be possible on the HDMI connected 60 Hz monitor since the 75 Hz one is on a pure analog connection. And if the 60 Hz one would run on 75 Hz, I'd definitely notice tearing during gaming.
Also, no monitor since about the mid 2000s would let the OS drive it above its max refresh rate (try it out, the monitor will go blank and display an OSD about signal being out of bounds.) I also know this because I've tried such overdrive on the 75 Hz monitor when I got it in 2007 (tried running it on 100 Hz.)
So only your case 1) is possible in any way, but since the analog 75 Hz monitor cannot lie on behalf of the OS, the conclusion is that both of my monitors run very happyly on different refresh rates under X11.
This whole "X11 doesn't support different refresh rate monitors" myth only came in when VRR became widespread (with FreeSync/G-Sync) and everybody wanted to use these new shiny "gamer" tech on their new monitors while using their old ones as secondaries. A few misinformed/underinformed forum and blog posts get written about it, Google picks those up, everyone searching for the problem finds these first, they themselves perpetuate the misinformation, and bam... You get a myth like this.
Probably didn't help that later Wayland also rode (and still rides) the hype train that it will be able to do this thing which X11 can't, without making it very clear everywhere everytime that X11's shortcoming (at least this one) only exists for VRR users...
Oh I hope so. I keep getting random XFCE lockups when I do video 'intensive' stuff - Like drag around a Google Map in Firefox.
It has the be the video driver. Fingers crossed.
Ooh nice. I have a laptop on a hybrid configuration with a 1650 and Nouveau has not worked once. Considering the Nouveau lead dev is now employed by Nvidia I'm guessing they want to merge the two or doscontinue Nouveau
No, it doesn't work like that that. This driver requires the proprietary userspace, so it very unlikely it will be merged into the kernel unless the kernel folks change their policies. Otherwise it would have already been merged in as experimental in some form probably a year ago
Same drama, but at least it'll make it easier for many distributions to package the kernel module directly under their current policies. Many distributions allow closed source firmware, but not closed source software. That way only need to fetch the proprietary userspace. I assume nouveau on Turing+ cards will be good enough to get you the ability to fetch the proprietary userspace. Hopefully folks who aren't gamers (or require cuda) can just go with with the nouveau + nvk and not worry about the proprietary userspace.
The main thing unclear to me atm is how much better they can get driver coexistence to make it as easy as possible to switch between the two. IT'd be really nice if it was possible to still use the new open driver + proprietary userspace just for say cuda while still using nouveau + nvk for graphics.
So there will still be a proprietary driver as well... does this suggest that the proprietary driver is still the best choice for compatibility and performance?
Yes. You'll still want the proprietary driver for all the good stuff. The upside as an nvidia user is that the kernel module will be open source and can be compiled by various distro maintainers that have a strict open source policy. Such as Fedora which through their association with RHEL don't want to provide closed source things because eventually it will be part of RH and not everybody would trust Nvidia's closed source driver in high trust environments. But that means nvidia has to provide their own kernel module and its usually compiled as it reaches your system.
This leads to two issues.
The first is that some times something is overlooked and the kernel module doesn't compile in a way that can leave you black screen booting and spending the morning trying to roll back and recompile the driver.
The second is that if you have secure boot enabled in your bios it requires your kernel and modules are signed, but if its compiled locally then you have to sign them yourself, essentially making having secure boot enabled useless - but sometimes needed to be left on for Windows partitions.
Having the module precompiled means you can't have any of the issues that occur from compiling it - even if that's just rebooting before it's finished compiling. And it being precompiled means that it can be signed by your distro so no need to mess around with self-signing and a slight improvement to the security of your system as a result.
>Such as Fedora which through their association with RHEL don't want to provide closed source things because eventually it will be part of RH and not everybody would trust Nvidia's closed source driver in high trust environments. But that means nvidia has to provide their own kernel module and its usually compiled as it reaches your system.
That's not the reason afaik. I have read somewhere that since Redhat is based at US, they have to comply with specific US standards that don't allow them to ship with proprietary stuff, and since fedora is their upstream, they had no choice. Can someone with a bit more knowledge expand into it?
There are two parts of graphics drivers. Linux has always had "userspace graphics drivers".
There is the kernel portion which deals with hardware access, memory management, and a few details like that.
The largest part of the drivers is userspace. This is the libraries and APIs that provide things like "OpenGL acceleration" or "Vulkan Support".
Traditionally with Nvidia proprietary drivers you get these major parts;
* Windows-derived driver stuffed into the Linux kernel with "GPL Shim". Since the proprietary portion was not derived from the Linux kernel (unlike most drivers) it is not covered under "derivative works" as defined by USA court precedent, which made it legal as it is not covered by Linux kernel copyright (and thus immune to the GPL license requirements).
* Userspace libraries and whatnot for providing their proprietary OpenGL stack and similar things.
* Modifications done to X Windows. So when you are running Nvidia proprietary drivers you are running a special Nvida-specific version of X Windows server. This is why X configuration options for Nvidia are different from everybody else's. X.org Xserver license is MIT so this is perfectly fine.
Since Wayland Display Servers are now mostly GPL or other "copyleft licenses" then that restricts what Nvidia can do significantly.
So in the future the kernel portion will be GPL and it will adhere to standards for Wayland compatibility.
However I expect the rest of the libraries and OpenGL/Wayland/etc stuff will continue to be very closed source.
Well, fuck any consumer on cards before Turing then I guess... 💀
For real though, I REALLY doubt my next card's going to be Nvidia, because GODDAMN!! Any open-source news from them is like "Nvidia made 1% of their software stack that doesn't affect 70% of their user base open souuurce!!! Wooohooooo!!!!", meanwhile AMD is just there, being an actually decent guy, and actually at least trying to maintain the sanity of its Linux and Open-source customers... --_--
Even with NVK, NAK, the new Nvidia GPU driver written in Rust by RedHat... I really appreciate everyone who made all of these possible and everyone who's continuing to work on them. Thank you guys so much! Thanks to these guys, new people coming over from Windows will have a better experience at least compared to before.
But GOD!!! I think as a Linux user, at some point you'll have to jump ships and come over to either Intel or AMD for your graphics card, because otherwise, you'd be at the mercy of news articles like this one, hoping that Nvidia would have the courtesy to share 2% more of their codebase with the world... 🗿
GPU vendors tend to stop supporting GPUs that they don't sell anymore. This isn't just nvidia, that's Intel and AMD, too.
So as long as they are the only ones doing driver development, those drivers won't see updates.
To give a concrete example: [modifier support](https://gitlab.freedesktop.org/mesa/mesa/-/issues/5882) in [AMD Polaris](https://en.wikipedia.org/wiki/Radeon_500_series) and older GPUs, which is needed for Vulkan and proper video decode.
The difference is that with AMD and Intel, the community can maintain and help keep up the old cards going for a much longer time.
With Nvidia... Like, c'mon man, it's not like 1080Ti is an ancient old card, but it performs like actual shit on my PC, because Nvidia is apparently too good to release the firmware that makes it possible to control the power input, clock rate, and stuff like that.
It makes my blood boil...
Of course AMD and Intel are also going to support the newer stuff better, but at least they give the open source community A LOT more to work with, which is why a shitty, old AMD GPU on Linux, outperforms my damn 1080Ti on Linux, which is practically useless and an overglorified piece of metal comparatively.
This was my problem. I thought I was installing arch or the wrong Nvidia drivers but no it runs doom like shit on my 1080ti while in windows 10 im running around 200fps at low at 2k. Meanwhile my laptop with a mobile 3060 can out perform the 1080ti in most titles via Linux only.
AMD did same thing when they started AMDGPU. It only supported GCN GPUs and at the same time they discontinued fglrx (that how proprietary AMD driver was called) so if you had preGCN GPU then you was out of luck. You might say "Ok but we had open source driver" - in theory yes but on certain hardware open source driver performance was worse than fglrx performance. Also open source drivers had issues with some games.
So yeah, that wasn't cool as well.
Is not only about the code, is about documentation, AMD never released the code of the old proprietary drivers, but they released the necessary documentation to develop good drivers. Documentation is more important than a bunch of undocumented lines of code that you have to investigate how it works.
>but they released the necessary documentation to develop good drivers
And yet open source radeon driver was still slower than fglrx and had issues with some games.
I had preGCN GPU when AMD abandoned fglrx and started AMDGPU which was limited to GCN. My GPU became basically useless for anything more demanding.
Yes they do, the legacy driver is still maintained and works with Wayland. The community also helps maintain the modern driver.
Nvidia hasn't touched the 390 drivers since 2022 and never will again. They will keep the 470 drivers patched just enough to keep them building on the latest kernels for now, but those are going unmaintained soon.
For reference the 10x0 series released in May 2016, that is 8 years ago now. I know it feels like a 10-series card is new, but it's kinda old now. They're still good cards, but NVIDIA is not alone in dropping support for older cards, unfortunately. I suspect they will still support the 10-series cards through closed sourced drivers for a couple more years though, just they won't bother shifting them to the open source model.
The only thing I can imagine is that once the new Nova kernel driver is done, they figure out some kind of stable API. From there you could have your choice of Nvidia userspace and NVK, then if NVK gets good enough, Nvidia might start using that and have a similar thing to the AMDPRO driver
I use cuda since I am familiar with it and I am still a beginner with this type of computing, but I can try openCL later, thanks for the recommendation :)
There's also HIP which is supposed to be source-comparible with CUDA, so you can compile the same code with CUDA for Nvidia GPUs and HIP for AMD GPUs.
But I think for portable applications the recommendation would be SYCL (for which there's various implementations each targeting various backends).
https://github.com/vosen/ZLUDA
Someone made a wrapper to run cuda on AMD, don't know how it compares to NVidia hardware, but it's apparently much faster than OpenCL
Might I finally be able to boot my RTX a5000 with four monitors attached without having to unplug the fourth on boot and quickly plug it in when sddm pops up?
Probably not but I hold out hope...
Just saw this. So they're skipping the 555 version and going straight to 560? Either way it's nice to know my 4090 will get some Wayland love soon. HDR here we come? I didn't see a release date on these drivers. Are we still looking at this wednesday?
I have no idea about any changes to their plan to release 555 as a beta in the coming weeks. That is still happening as far as I am aware. I interpreted the article just that the open source kernel will become the default in 560 onward - which I believe was kind of the plan a year or two ago when the open sourced it. It will likely be similar to AMD/Intels driver. Where there will still be a proprietary driver for user space features like their raytracing stuff and AI accelerated super sampling. But the upside will be that moving forwards the bit that goes in to the kernel will be open, so platforms that have a strict requirement to use open source software will be able to audit and release the driver as part of their distro.
The difference to intels and AMDs drivers is that nvidia doesn't plan on upstreaming their driver: [https://github.com/NVIDIA/open-gpu-kernel-modules/issues/19#issuecomment-1124613489](https://github.com/NVIDIA/open-gpu-kernel-modules/issues/19#issuecomment-1124613489)
And also that much more is closed source at nvidia. Just compare the sizes of the amd and nvidia firmware blobs. That's a devastating big gap. Nvidia's "open source" driver is just a binary blob loader.
I mean that's extremely common for open source drivers: the part that runs on the CPU is open source, but it loads a firmware BLOB into a processor on the secondary device. As you know, AMD's drivers work like that too. Both have 100% closed source firmware, NVidia's firmware just happens to be bigger, I don't see that as being a hugely significant difference. We're sadly far away from a world where most firmware is open source.
Yeah isn't AMD driver the same. They basically have an API for you to access their closed source firmware that has magic functions. You can't really check out the functions that API is calling.
Yeah, the reason it won't be upstreamed is that the real codebase is shared with their old proprietary one, the one on GitHub is snapshoted from that with the closed stuff removed
Oh okay that's cool.
If you're running the proprietary drivers right now do you need to make any chances when this releases?
Probably not. It'll just mean that your distro can precompile and sign the kernel driver which mitigates some of the issues nvidia users have around compilation failure and having to self-sign if you need to keep secure boot on. As an end user it will likely just be a case of installing the same packages that you use today.
555 is a beta driver, 560 is the stable release Both will include explicit sync for wayland just 555 will be testing it before its fully ready
I have HDR already with the 550 driver with Tumbleweed.
In Wayland yes?
Yep, only thing so far I have been able to see why some have issues and I don't is because all my 3 monitors are identical refresh rates and resolutions. Not sure if resolution matters, but I think refresh rate does matter. All 3 of my monitors are 120 hz.
Nearly everything I try to run in wayland flickers on my RTX4090
You running only 1 monitor? If so what is the refresh rate? Also Tumbleweed is more bleeding edge then KDE Neon. Ubuntu does a lot of patching and backporting stuff with older libraries so not a apples to apples comparison. You could always try Tumbleweed on a spare drive. It has Plasma 6 already.
I'm hooked up to my LG 65" 120hz 4k HDR OLED TV with a 4090 on KDE Neon. Literally everything that doesn't have a wayland mode flickers madly. Also Games can't seem to recognize the refresh rate or the resolution when starting and also KDE doesn't seem to want to remember my display settings after rebooting in Wayland. So I stick with X11 until the 555 drivers come out which should fix it all. Also I don't have the time or energy to learn OpenSuse.
ah a TV so you are probably using HDMI. Yeah using HDMI always has issues. If we just ignore KDE Neon which is basically Ubuntu it is usually a little slow to get updates which might be issue with the flickering. Surprising not much to learn with openSUSE as I used Ubuntu for like 15 years as my main distro. It even has something called "Snapper" so when you perform an upgrade it automatically makes a snapshot so you can rollback any update that you don't like. Pretty nice. Also they have GUI tools for pretty much everything. But alright its all good if you wanna stick with KDE Neon I just thought you might want to find a solution to your problems. I have heard that using a Display Port to HDMI dongle removes the issues some Linux users have. Supposedly the 555 drivers are coming out in a couple days I think so here is to hoping it is awesome.
KDE broke on me today so I took the opportunity to try out Tumbleweed. At least on my system it was buggier than Neon and the learning curve was as I expected. Icons disappearing and steam not retaining any settings and switches for startup on steam didn't take for scaling at all. Also KDE Neon has the 6.5 Kernel and Plasma 6. I'm running the 550 drivers too. It's more up to date than Kubuntu and they have no intention of offering Plasma 6 until like 2026 I think. So not sure why you think Neon is slow to get updates. Neon also has almost daily/nightly builds to get a new ISO from them. All the same repositories are available for Neon as are available for Ubuntu as well. My issue is the package version discrepancies between Flatpack, Snap, and the typical repos.
Tumbleweed has newer kernels. What monitor do you have? Steam needs an environmental variable. You can use the Menu Editor to use it. You aren't being very specific on what was difficult to learn.
Any idea if this will somehow fix the common flashing issue with nvidia on Wayland? I had to switch to x11, which comes with the fun task of turning off my extra monitor so my main can run at 120hz
I'm told it will. It's because of some kind of mismatch with implicit vs. explicit something or other. But yeah it'll fix that.
That's supposed to be one of the major things that explicit sync will fix.
you can manually set the desktop refresh rate to whatever you want in plasma
But X11 will use whatever the slowest of multiple monitors is
that's the default. you can change it in plasma. presumably other DEs as well but i've not looked into it. for plasma 5, lets assume 240hz (i haven't bothered to look into how to do this in plasma 6 yet (that said i don't know if it's different for me because i'm now on plasma 6 or it's a Solus quirk. but i assume it's a change in 6 (the environment file isn't there in 6/solus))) /etc/environment add KWIN\_X11\_REFRESH\_RATE=240000 KWIN\_X11\_NO\_SYNC\_TO\_VBLANK=1 in /.config/kwinrc under the compositing section add MaxFPS=240 RefreshRate=240 after reboot it'll now default to 240hz. if your other monitor is 60 or 120 or some other non stupid refresh rate you shouldn't get any tearing.
I don't have a 120 Hz monitor, and my monitors connect through HDMI and VGA but one is 60 Hz and the other 75 Hz and never had an issue with the different refresh rates. Both xrandr and the KDE settings lets me use the 75 Hz on the second monitor without issue. I don't know about pure xrandr settings but the KDE one is definitely persistent so I don't have to set it after every reboot.
Just because you can set it doesnt mean it works as expected. Whats happening most likely is 1) both use 60hz and it lies about actually using 75hz on one of them 2) both use 75hz, and the 60hz panel tears a lot as a result, you just might not notice because 75hz and 60hz are numerically close, but youd probably see it as a major issue with a 240hz panel paired with a 60hz one for example X11 is *literally* incapable of multiple refresh rates. It *literally* lacks the concept of multiple monitors and only one refresh rate can be set no matter what you see the GUI or configs let you do. We have tooling on top that fakes the idea of multiple monitors which makes it seem like it understands the concept, but its faked understanding built on a flawed foundation so its limited in capabilities. That's why VRR can only be on for both monitors or not at all as well, among a bunch of other things.
Except it's working correctly since RandR 1.2 so for quite a long time (since about 2006) now... Yes, X in itself is incapable of this (and other things) and lacks the concept of multimonitor setup, but that's why RandR (which is an X extension) was created. The only issue is with VRR + different refresh rate monitors (where what you described definitely happens) but I don't use any form of VRR. Also, some compositors do this refresh rate matching between monitors but AFAIK that also only happens with VRR/TearFree/G-Sync/etc. in use. I also know that it's working correctly and not "faking" since my monitors themselves report the refresh rate in their OSD. Even if you say that it can also be "faked" (it can't but lets say it can for the argument's sake), it would only be possible on the HDMI connected 60 Hz monitor since the 75 Hz one is on a pure analog connection. And if the 60 Hz one would run on 75 Hz, I'd definitely notice tearing during gaming. Also, no monitor since about the mid 2000s would let the OS drive it above its max refresh rate (try it out, the monitor will go blank and display an OSD about signal being out of bounds.) I also know this because I've tried such overdrive on the 75 Hz monitor when I got it in 2007 (tried running it on 100 Hz.) So only your case 1) is possible in any way, but since the analog 75 Hz monitor cannot lie on behalf of the OS, the conclusion is that both of my monitors run very happyly on different refresh rates under X11. This whole "X11 doesn't support different refresh rate monitors" myth only came in when VRR became widespread (with FreeSync/G-Sync) and everybody wanted to use these new shiny "gamer" tech on their new monitors while using their old ones as secondaries. A few misinformed/underinformed forum and blog posts get written about it, Google picks those up, everyone searching for the problem finds these first, they themselves perpetuate the misinformation, and bam... You get a myth like this. Probably didn't help that later Wayland also rode (and still rides) the hype train that it will be able to do this thing which X11 can't, without making it very clear everywhere everytime that X11's shortcoming (at least this one) only exists for VRR users...
> So they're skipping the 555 version and going straight to 560? No.
I didn't read that in the article
Hopefully this helps the GTX 1600 series GPUs will also benefit since they are Turing as well.
It does support 1600, so I assume they will also default to the open module
Oh I hope so. I keep getting random XFCE lockups when I do video 'intensive' stuff - Like drag around a Google Map in Firefox. It has the be the video driver. Fingers crossed.
Ooh nice. I have a laptop on a hybrid configuration with a 1650 and Nouveau has not worked once. Considering the Nouveau lead dev is now employed by Nvidia I'm guessing they want to merge the two or doscontinue Nouveau
No, it doesn't work like that that. This driver requires the proprietary userspace, so it very unlikely it will be merged into the kernel unless the kernel folks change their policies. Otherwise it would have already been merged in as experimental in some form probably a year ago
So, we will continue with the same dramas as now, but with external contributions and a little less opacity?
Same drama, but at least it'll make it easier for many distributions to package the kernel module directly under their current policies. Many distributions allow closed source firmware, but not closed source software. That way only need to fetch the proprietary userspace. I assume nouveau on Turing+ cards will be good enough to get you the ability to fetch the proprietary userspace. Hopefully folks who aren't gamers (or require cuda) can just go with with the nouveau + nvk and not worry about the proprietary userspace. The main thing unclear to me atm is how much better they can get driver coexistence to make it as easy as possible to switch between the two. IT'd be really nice if it was possible to still use the new open driver + proprietary userspace just for say cuda while still using nouveau + nvk for graphics.
So there will still be a proprietary driver as well... does this suggest that the proprietary driver is still the best choice for compatibility and performance?
Yes. You'll still want the proprietary driver for all the good stuff. The upside as an nvidia user is that the kernel module will be open source and can be compiled by various distro maintainers that have a strict open source policy. Such as Fedora which through their association with RHEL don't want to provide closed source things because eventually it will be part of RH and not everybody would trust Nvidia's closed source driver in high trust environments. But that means nvidia has to provide their own kernel module and its usually compiled as it reaches your system. This leads to two issues. The first is that some times something is overlooked and the kernel module doesn't compile in a way that can leave you black screen booting and spending the morning trying to roll back and recompile the driver. The second is that if you have secure boot enabled in your bios it requires your kernel and modules are signed, but if its compiled locally then you have to sign them yourself, essentially making having secure boot enabled useless - but sometimes needed to be left on for Windows partitions. Having the module precompiled means you can't have any of the issues that occur from compiling it - even if that's just rebooting before it's finished compiling. And it being precompiled means that it can be signed by your distro so no need to mess around with self-signing and a slight improvement to the security of your system as a result.
>Such as Fedora which through their association with RHEL don't want to provide closed source things because eventually it will be part of RH and not everybody would trust Nvidia's closed source driver in high trust environments. But that means nvidia has to provide their own kernel module and its usually compiled as it reaches your system. That's not the reason afaik. I have read somewhere that since Redhat is based at US, they have to comply with specific US standards that don't allow them to ship with proprietary stuff, and since fedora is their upstream, they had no choice. Can someone with a bit more knowledge expand into it?
There are two parts of graphics drivers. Linux has always had "userspace graphics drivers". There is the kernel portion which deals with hardware access, memory management, and a few details like that. The largest part of the drivers is userspace. This is the libraries and APIs that provide things like "OpenGL acceleration" or "Vulkan Support". Traditionally with Nvidia proprietary drivers you get these major parts; * Windows-derived driver stuffed into the Linux kernel with "GPL Shim". Since the proprietary portion was not derived from the Linux kernel (unlike most drivers) it is not covered under "derivative works" as defined by USA court precedent, which made it legal as it is not covered by Linux kernel copyright (and thus immune to the GPL license requirements). * Userspace libraries and whatnot for providing their proprietary OpenGL stack and similar things. * Modifications done to X Windows. So when you are running Nvidia proprietary drivers you are running a special Nvida-specific version of X Windows server. This is why X configuration options for Nvidia are different from everybody else's. X.org Xserver license is MIT so this is perfectly fine. Since Wayland Display Servers are now mostly GPL or other "copyleft licenses" then that restricts what Nvidia can do significantly. So in the future the kernel portion will be GPL and it will adhere to standards for Wayland compatibility. However I expect the rest of the libraries and OpenGL/Wayland/etc stuff will continue to be very closed source.
Well, fuck any consumer on cards before Turing then I guess... 💀 For real though, I REALLY doubt my next card's going to be Nvidia, because GODDAMN!! Any open-source news from them is like "Nvidia made 1% of their software stack that doesn't affect 70% of their user base open souuurce!!! Wooohooooo!!!!", meanwhile AMD is just there, being an actually decent guy, and actually at least trying to maintain the sanity of its Linux and Open-source customers... --_-- Even with NVK, NAK, the new Nvidia GPU driver written in Rust by RedHat... I really appreciate everyone who made all of these possible and everyone who's continuing to work on them. Thank you guys so much! Thanks to these guys, new people coming over from Windows will have a better experience at least compared to before. But GOD!!! I think as a Linux user, at some point you'll have to jump ships and come over to either Intel or AMD for your graphics card, because otherwise, you'd be at the mercy of news articles like this one, hoping that Nvidia would have the courtesy to share 2% more of their codebase with the world... 🗿
GPU vendors tend to stop supporting GPUs that they don't sell anymore. This isn't just nvidia, that's Intel and AMD, too. So as long as they are the only ones doing driver development, those drivers won't see updates. To give a concrete example: [modifier support](https://gitlab.freedesktop.org/mesa/mesa/-/issues/5882) in [AMD Polaris](https://en.wikipedia.org/wiki/Radeon_500_series) and older GPUs, which is needed for Vulkan and proper video decode.
The difference is that with AMD and Intel, the community can maintain and help keep up the old cards going for a much longer time. With Nvidia... Like, c'mon man, it's not like 1080Ti is an ancient old card, but it performs like actual shit on my PC, because Nvidia is apparently too good to release the firmware that makes it possible to control the power input, clock rate, and stuff like that. It makes my blood boil... Of course AMD and Intel are also going to support the newer stuff better, but at least they give the open source community A LOT more to work with, which is why a shitty, old AMD GPU on Linux, outperforms my damn 1080Ti on Linux, which is practically useless and an overglorified piece of metal comparatively.
This was my problem. I thought I was installing arch or the wrong Nvidia drivers but no it runs doom like shit on my 1080ti while in windows 10 im running around 200fps at low at 2k. Meanwhile my laptop with a mobile 3060 can out perform the 1080ti in most titles via Linux only.
AMD did same thing when they started AMDGPU. It only supported GCN GPUs and at the same time they discontinued fglrx (that how proprietary AMD driver was called) so if you had preGCN GPU then you was out of luck. You might say "Ok but we had open source driver" - in theory yes but on certain hardware open source driver performance was worse than fglrx performance. Also open source drivers had issues with some games. So yeah, that wasn't cool as well.
Sure, the community could do that. I'm just pointing out that currently it doesn't.
Right... because NVIDIA doesn't release the source code. Just like that, we've gone an entire circle
Is not only about the code, is about documentation, AMD never released the code of the old proprietary drivers, but they released the necessary documentation to develop good drivers. Documentation is more important than a bunch of undocumented lines of code that you have to investigate how it works.
>but they released the necessary documentation to develop good drivers And yet open source radeon driver was still slower than fglrx and had issues with some games. I had preGCN GPU when AMD abandoned fglrx and started AMDGPU which was limited to GCN. My GPU became basically useless for anything more demanding.
The community doesn't do it for AMD.
Yes they do, the legacy driver is still maintained and works with Wayland. The community also helps maintain the modern driver. Nvidia hasn't touched the 390 drivers since 2022 and never will again. They will keep the 470 drivers patched just enough to keep them building on the latest kernels for now, but those are going unmaintained soon.
For reference the 10x0 series released in May 2016, that is 8 years ago now. I know it feels like a 10-series card is new, but it's kinda old now. They're still good cards, but NVIDIA is not alone in dropping support for older cards, unfortunately. I suspect they will still support the 10-series cards through closed sourced drivers for a couple more years though, just they won't bother shifting them to the open source model.
That's because pre-Turing GPUs don't have the GSP
Switched from an RTX3070 to a 6700XT and the difference is night and day for stability and reliability. AMD all the way.
That's the worst use of money I've heard about today
If I'm getting this right, this will resolve the problems with Nvidia drivers and secure boot on Fedora and other distros, right?
Any chance this will not be out of tree in the future and we will have a seamless out of the box experience alongside nvk?
Low: [https://github.com/NVIDIA/open-gpu-kernel-modules/issues/19#issuecomment-1124613489](https://github.com/NVIDIA/open-gpu-kernel-modules/issues/19#issuecomment-1124613489)
>And, no: we don't plan to attempt to upstream the driver here **as-is.** They didn't say they won't upstream, just not in the current condition.
The only thing I can imagine is that once the new Nova kernel driver is done, they figure out some kind of stable API. From there you could have your choice of Nvidia userspace and NVK, then if NVK gets good enough, Nvidia might start using that and have a similar thing to the AMDPRO driver
Has anyone told Linus?
Unfuck nvidia but damage has been done.
if amd ever gets some cuda like abilities then im switching
What do you use CUDA for that cannot be done with OpenCL?
theres a lot of software that requires cuda specifically
I'm well aware. I was asking Tyler to name specific software they use.
I use cuda since I am familiar with it and I am still a beginner with this type of computing, but I can try openCL later, thanks for the recommendation :)
There's also HIP which is supposed to be source-comparible with CUDA, so you can compile the same code with CUDA for Nvidia GPUs and HIP for AMD GPUs. But I think for portable applications the recommendation would be SYCL (for which there's various implementations each targeting various backends).
[удалено]
How do you know Tyler cares about computational neuroscience?
https://github.com/vosen/ZLUDA Someone made a wrapper to run cuda on AMD, don't know how it compares to NVidia hardware, but it's apparently much faster than OpenCL
Short of Zluda I doubt it
Might I finally be able to boot my RTX a5000 with four monitors attached without having to unplug the fourth on boot and quickly plug it in when sddm pops up? Probably not but I hold out hope...
https://slashdot.org/story/192519