Nouveau GPU System Processor (GSP) firmware integration that allows making use of NVIDIA’s binary GSP firmware on RTX 20 “Turing” and newer GPUs for having improved support. In turn this GSP route also provides initial support for GeForce RTX 40 series support.
tl;dr some preparation for hopefully better Nvidia open source driver support in the future
Great to see, sadly I wouldn’t be able to use it. I have GTX 10 series and the next one I will be buying is AMD or maybe Intel, if their drivers get a lot better by the time I am in a market for a new GPU.
Yep, I have a RTX 2080 and am picking up a 6700 XT once my pay check lands later today (put in a bit of extra time to justify the cost) - I’ve given Nvidia more than enough time to get their act together.
I have heard that Intel had just recently released a pretty decent update to their driver, I haven’t been following it too closely but there’s certainly hope.
Can I ask why 6700? In raster performance it’s only about 10 faster than 2080 and in ray tracing it is worse. It might be a bit different on linux, but either way, when I will be upgrading I want better improvement than that.
I don’t really need to play the latest games, so I can easily wait. My next gpu will probably be 8800xt or even 9800xt
Primarily because my income doesn’t really allow for me to go any higher than that, I already worked a bit overtime last month since the opportunity was available in order to be able to pick it up. Short of a GPU magically falling from the sky, it was always going to be a lateral move at best. I’d love to either not have to spend money on a card that isn’t really going to gain me a performance boost (and I don’t do any raytracing, my gaming is still fairly lightweight - I’m still on 1080p 60Hz monitors for example), but Nvidia’s stupid games (ha) is pretty much forcing my hand.
As of right now, using Wayland is nigh impossible for me due to the this issue and a fix is a long way out from now because it requires approval on an explicit sync protocol, and then every single compositor will need to implement it - assuming it was approved fairly quickly, its not likely to land in KDE Plasma 6’s initial release, and I doubt it’ll make it in time for GNOME’s next release in the spring. If I used only Wayland-native apps it’d be fine, but that’s not the case - my IDE that I use for work for example uses XWayland and experiences the linked issue very heavily and makes it impossible to actually do any work in. Not to mention, most games still use XWayland since they run through WINE/Proton which doesn’t have Wayland support yet. But hey, at least Night Light/Color finally works in Wayland as of 545 (which don’t even get me started on how ridiculously long that took to get in)…
X11 is hugely problematic because I can hardly reach 60 FPS on just the desktop with basic windows open, the closest I can get is by running KDE and replacing the compositor responsibilities with picom, which has its own fair share of issues. I’ve spent all year trying various tweaks, driver versions, playing around with X/Nvidia settings, using KWin’s and GNOME’s triple buffer (patch), and this was the best I can do.
I was really banking on 545 fixing the situation with Wayland, but that’s not going to happen anytime soon given explicit sync needing to be added into XWayland - or Nvidia rewriting their driver to use implicit sync (which is a pipe dream, given that their driver’s unified architecture means that on Windows it would need to do implicit sync as well). NVK is still a fair bit out from being anywhere near production ready AFAIK, and nouveau is probably still a bit out there as well.
Ironically, Nvidia’s driver in Windows is also upsetting me. I get a stranger flicker from what I believe is the same issue as what was just fixed in 545 which is the power-state of the GPU changing. So this happens even when Steam draws its “Your friend is playing some game” notification, or opening a YouTube video.
Funnily enough, I didn’t even buy the 2080, it was passed down to me from a friend along with a few other components - I was previously on a GTX 970 which was… painful as I’m sure you can imagine due to its age, and wasn’t helped by Nvidia’s drivers being horrendous.
I’m not even a hardware person by any means (for various reasons, such as physical ailments), it was an accomplishment for me to be able to effectively tear down my old build, and replace all of the internals (PSU, Motherboard+CPU+RAM, GPU, liquid cooler… the whole works, only the case stayed the same really) so I’ll just be happy if I can get my new card swapped in without any issues. If one thing goes right for me this month, I just want it to be that.
At the end of the day, I just want my PC to work (and to let me literally work), and everything else is perfect and fully capable - well, I’m a bit disappointed by my new Intel WLAN card being shoddy in Linux but that’s a whole other story. Probably a lot longer of an answer than you expected, but that about sums it up haha.
I guess that’s fair if you need AMD GPU right now for work.
I am fed up with Nvidia drivers too. Games run smoother on my Steam Deck than on my PC. Like I have higher average FPS on my PC but the frame time graph are spikes after spikes. And on Steam Deck frame time graph is smooth line.
Definitely know where you’re coming from.with the frametime issues, I see the same thing whether in X or Wayland.
I thought that was just the state of Linux gaming for a while, since I hadn’t known anyone else personally who was using Linux (let alone playing games on top of that). It wasn’t until the Steam Deck came out which tons of my friends have that I realized “this is just another Nvidia thing is it”…
Exactly the same thing, I just thought that was Linux gaming “it is what it is”, until I got steam deck.
I’m wondering whether the open source nvk driver will work with exclusive nvidia features like DLSS.
CUDA probably won’t work either, just like AMD’s RADV doesn’t do the common compute APIs. Maybe they’ll support Vulkan compute, but that’s not as useful.
AMD’s RADV doesn’t do the common compute APIs
RADV is just the Vulkan driver to be clear, so the other APIs are implemented separately. ROCm is supported by some cards, and Rusticl is the currently most advanced OpenCL implementation in Mesa (with Clover on the way out). Vulkan compute is implemented in RADV, although I found it to be slightly slower than the AMDVLK implementation (AMD’s official Linux Vulkan driver, developed out of tree).
As for Nvidia, it’s likely to be a worse situation since Nvidia don’t have a bunch of open APIs, just closed ones. Vulkan compute I would expect at least, if not immediately.
As for CUDA, it might work if you’re willing to have a hybrid open/closed system. On AMD this is possible, where you can generally install and enable/disable the AMDGPU-PRO compute and Vulkan drivers on demand.
I won’t be buying an NVIDIA GPU any time soon for my desktop, but hopefully this move will make gaming on my laptop better. Unfortunately NVIDIA seems to have an almost monopoly on good gaming laptops especially if you don’t want giant bulky or cheaply built ones. My 2021 Razer Blade 14 has a 3070 and while the proprietary drivers work, NVIDIA’s own implementation of render offloading/PRIME leaves much to be desired, with random screen tearing even when vsync is forced on as soon as the GPU load starts getting high.
I think you have to be okay with APUs to be satisfied with AMD on laptops. Which at least are decently powerful these days, as long as high res triple AAA gaming isn’t a requirement (the Steam Deck is just an APU after all).
I hope they will also upstream blob-lock(firmware needs to be signed by nvidia) bypass.
strong
mmm cum
