Nvidia's next Linux driver to be… just as open Nvidia says its forthcoming release 560 driver will be as open as releases 515 and 555 were – and will support more devices. The latest emission from Big Green boldly states Nvidia Transitions Fully Towards Open-Source GPU Kernel Modules. What this means is that it's continuing the 2022 move to open source its graphics …
I used Nvidia cards for ages but was always bumping into problems trying to get xorg.conf running smoothly. I found that worthy as Noveau is it didn't handle the jobs I needed it to, so it was edit xorg.conf and hope that it would work.
In the end I gave up and switched to Radeon/AMD and so far have had absolutely no problems.
I suppose Nvidia must have a reason for keeping its cards close to its chest but in my case all that happened was that Nvidia lost o a long time customer.
F Nvida and the horse they rode into town on. Drop those prices in half and we can overlook it.
Nvidia really doesn't care about home market customers like me and you. They've been making big bucks from cryptocoin mining, data center GPU processing, and AI.
Unless... you're an AI.
Are you an AI?
[Author here]
> In the end I gave up and switched to Radeon/AMD and so far have had absolutely no problems.
I have to admit, when I ran openSUSE (and Windows in dual-boot) and switched from nVidia to AMD, it was a revelation. Months of graphics driver related pain and suffering just... stopped. And everything just started working, as if by magic. In both Win10 and in Linux.
Intel graphics: no problem, just works.
AMD graphics: no problem, just works.
nVidia graphics: problem. Then another, then another.
All the gamers: BUT MY FRAMERATES!
It's dead easy. Just do 2 things:
1. Leave your baggage at the door. All your assumptions. Doesn't matter how well you know Windows: knowing Windows is _not_ knowing computers. Windows techniques and methods _will not work_. Don't even try. Every time you want to do something you think you know how to do, GOOGLE IT.
2. At first, dual boot. Turn off Bitlocker and any and all disk encryption. Turn off hibernation. Turn off Fast Start. Turn off RAID mode in your disk controller. Turn off Secure Boot. Clean up Windows, CHKDSK it, defrag it, and shrink your C drive as small as it will go.
And if you have any choice, _don't use nVidia kit_.
>I suppose Nvidia must have a reason for keeping its cards close to its chest but in my case all that happened was that Nvidia lost o a long time customer.
Market forces.
NVidia, like almost every hardware maker, makes different products at different prices with fundamentally the same parts. This makes stuff cheaper for everyone - the components are cheaper in larger batches and the buyers of the higher end cards subsidise the mass market cheaper cards.
We used to have to buy the "professional" Quadro cards because they supported features like synchronised outputs. If there were open source drivers then someone would have enabled Quadro features on GFX cards, or enabled high end features on low end cards. The price of the lower cards would have to rise to maintain margins.
With AI super-monster-GPUs NVidia aren't crippling the H100 to make a cheaper version with the same chips, they are pushing every working chip out of the door. SO there is no need to restrict functions in software, improving your own drivers is just costing you money vs letting the community do it for you
I have had a couple of Intel/nVidia machines over the years, running Debian or Ubuntu. I generally never got adequate graphics performance out of them, even when running the proprietary drivers. I recently acquired a Dell 2-in-1 with an AMD/Radeon CPU and GPU, running Ubuntu. I get decent graphics now; while I would never use this machine for serious gaming, it satisfies my needs. And, I can run the Sway window manager, whose principal developer refuses to support nVidia (even though you can make it sort-of work).
Windows users probably don't care about this, but as things stand, I'd be very reluctant to buy another nVidia-based machine, at least until Linus changes his mind.
[Author here]
> Why the hell does a window manager care about the graphics card?
Sway is a Wayland compositor. It _only_ runs with Wayland. That means the window manager *is* the display server. That is what a Wayland compositor *is*.
> That's the X Server's job.
There isn't one. In a Wayland setup, the X server is more or less another app that runs under the compositor.
> Sounds like a shitty window manager.
No comment. I haven't tried it. I am not a particular terminal warrior so I am not fond of tiling window managers: I prefer tiling to be an optional feature of my conventional desktop.
But nVidia has been very unhelpful with FOSS OSes in general, especially Linux, and in particular with GUIs and with Wayland, so I respect someone simply refusing to play.
If future drivers will be as good as legacy x11/nvidia-driver-470 on FreeBSD 15.0-CURRENT, I'll be happy.
Things are pretty much rock-solid for me with a GK107GLM (Quadro K1100M).
No offence to porters, but prior experience with i915kms was occasionally flaky.
I don't own NVIDIA, I'm not a shareholder, I'm an end user, it's not my place to complain about closed source firmware if the firmware works as required.
If it starts running on all the BSDs (i.e. not just FreeBSD using the proprietary driver) I'll accept maybe Nvidia have finally changed their standards. Until then for running any of the smaller Unix it's AMD or possibly Intel all the way (haven't looked at the latest Arc support).
Have to say though, my experience with AMD drivers has in general been much worse than Nvidia. My now old Vega 56 is working fine, but there have been numerous Windows releases where they spent literally a year to fix notable issues with OpenCL related crashes, VR, and having the AMD card not be the primary card. Nvidia cards work *far* better for PCIe passthrough than AMD too. I had similar issues with the HD6950 years ago, and I'm aware the 7900XTX, their top end card, had severe VR issues for over a year.
Given Nvidia fairly recently fixed their drivers to work properly under Wayland, when I do upgrade my graphics card it's likely to be an Nvidia one as they directly support Windows, FreeBSD, and Linux. AMD don't want to make the investment to capture the market. Intel are competitive, but only if you fit their usage profile of DirectX12 and Vulkan last time I looked. If you want OpenGL or VR it's a poor choice.
I use Linux rather than BSD now but the main reason for that is because there was certain stuff that just didn’t work for BSD.
It’s very annoying that these days, open source seems to mean “Linux” at the expense of everything else. And this seems to occur with a certain arrogance from some areas.
I would MUCH rather use BSD - I think Linux is a mess - but this prevailing thinking is doing a lot of harm. All it’s doing is creating yet another monoculture, and this week’s debacle with Crowdstrike tells us how healthy that is!!
Just to describe what is going on with the firmware... the power management and clock management stuff was in the binary blob driver, while with noveau (due to unavailability of power control at all) many cards were locked at minimum clock speed, so you'd have this 4090 or whatever but it's running at like 200mhz.
The newer cards have a RISC-V CPU on them, which I have no idea what it was doing before if anything. They now have that whole part of the driver running on the RISC-V CPU on the card instead.
It's not ideal, but I mean, the Intel wifi cards do this -- the older ones had tons and tons of stuff in the driver to control power on the chip, the amplifier (including like temperature coefficients and stuff, it was directly poking some oscillators, I mean the driver code looks totally nuts on these things.) Newer ones, the firmware does it and the drivers call some API. Even for the wifi stack itself, you have "SoftMAC" cards where the wifi card is relatively dumb and the driver has pretty much a whole wifi stack in it (or in Linux the driver providing low-level functions and mac80211 layer doing the protocols, WEP/WPA/WPA2/WPA3, etc.) , with a "HardMAC" card there's some API, the driver tells the card what to do and it takes care of low-level details.
This has been an argument in open source for many years.. but to me, if a binary blob is running on the CPU, it's not good. If it's just being loaded onto a device, who cares? Nobody complained when it was burned into a ROM instead.
Side note, I'm running a GTX1650 with 550 driver -- maybe I should switch to the open source one, see if I get any extra FPS or whatever. I think the driver CPU usage is supposed to be lower, nvidia driver is known to be rather CPU intensive compared to the Intel or AMD Mesa drivers (and I think it's higher in Windows too? I don't know, I don't use it), I assume if like half the driver is now being run on the card that it'd lower the host system's CPU consumption.
Now that there's no binary blobs invovled (well, there is but it's just sent to the card, not executed on the host CPU), presumably the driver could be ported to OpenBSD? I mean in the past you literally had some C code that was just a shim between this big binary blob and the Linux or Windows kernel, now you do have this open source code that can be fully adapted.
As for Intel OpenGL -- with the Mesa Gallium 3D drivers, in fact the OpenGL support is quite good. You can run something ancient like Ivy Bridge and still have OpenGL 4.2, and you've got full 4.6 (along with Vulkan on almost anything newer than that; and Vulkan with VM_BIND support on new enough GPUs, i.e. the "Intel Xe" as found in Tiger Lake or newer, or the Arc GPUs.)
...are NVIDIA related these days.
I've been daily driving Linux for decades now and the days of dodgy wifi etc etc are long gone...it's literally just NVIDIA left to sort their shit out.
The only time I come up against dodgy driver issues is with the occasional Realtek chip or something.
On the server side I can't remember ever having a Linux specific issue with hardware / drivers. Usually in the case of a driver being crap on a particular server it applies to Windows as well (and is usually worse).
The only hardware that ever poses some kind of issue is for those crappy USB licensing dongles you get for various software. Usually in that situation though you can do some binwalk / hexediting magic to make the dongles unnecessary...ssshh...don't tell anyone!
Wow, all the hate for nVidia. I am running an nVidia card with Mint, using the proprietary driver and it ... works very well, as in, not a problem at all
I'm rendering 3D scenes with the GPU and it's as smooth as. As far as game performance goes I have no idea as I don't play graphics heavy games.
I don't get all bent out of shape about being "pure" and refusing to run the proprietary driver as I like to use what gets the job done.
I like to use what gets the job done.
Yes, so do I, that's why I switched away from Nvidia to AMD.
Personally I don't "hate" Nvidia. How can you hate a faceless corporation?
What I did hate was all the unnecessary faffing about trying to get the bloody video card to work. So I changed brand and my problems were solved.
A win for me, a win for AMD and a loss for Nvidia.
Mint uses older versions of the drivers by default. The main problem with NVIDA is the newer drivers that support newer cards. For anything older than a 40 super, you can use the older driver, but the 40 super series only works with the newer driver, which is broken as fuck...especially with Electron apps and Wayland.
I don't have this hate myself. But :people will want to run a bleeding edge kernel and find the nvidia driver won't build, they have to wait for an update. (I did run into that when I ran gentoo.. so I jjust sucked it up and put off updating to that newest kernel for a week or two.). Or they'd have problems with HDR or variable refresh rates (which :eople have issues with with amd or intel setups too, to be honest.)
I do game, and have found my GTX1650 to be perfectly serviceable, my GTX650 was fine, My Gerorce 4 MX440 was a piece of crap, essentiallty a rebadged Geforce 2 but the driver was fine on that too.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
