[HN Gopher] NVIDIA Transitions Fully Towards Open-Source Linux G...
___________________________________________________________________
NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel
Modules
Author : shaicoleman
Score : 298 points
Date : 2024-07-17 18:40 UTC (4 hours ago)
(HTM) web link (developer.nvidia.com)
(TXT) w3m dump (developer.nvidia.com)
| hypeatei wrote:
| How is the NVIDIA driver situation on Linux these days? I built a
| new desktop with an AMD GPU since I didn't want to deal with all
| the weirdness of closed source or lacking/obsolete open source
| drivers.
| tadasv wrote:
| great. rtx 4090 works out of the box after installing drivers
| from non-free. That's on debian bookworm.
| jppittma wrote:
| 4070 worked out of the box on my arch system. I used the closed
| source drivers and X11 and I've not encountered a single
| problem.
|
| My prediction is that it will continue to improve if only
| because people want to run nvidia on workstations.
| jcranmer wrote:
| I built my new-ish computer with an AMD GPU because I trusted
| in-kernel drivers better than out-of-kernel DKMS drivers.
|
| That said, my previous experience with the DKMS driver stuff
| hasn't been bad. If you use Nvidia's proprietary driver stack,
| then things should generally be fine. The worst issues are that
| Nvidia has (historically, at least; it might be different for
| newer cards) refused to implement some graphics features that
| everybody else uses, which means that you basically need
| entirely separate codepaths for Nvidia in window managers, and
| some of them have basically said "fuck no" to doing that.
| mepian wrote:
| The current stable proprietary driver is a nightmare on Wayland
| with my 3070, constant flickering and stuttering everywhere.
| Apparently the upcoming version 555 is much better, I'm
| sticking with X11 until it comes out. I never tried the open-
| source one yet, not sure if it supports my GPU at all.
| llmblockchain wrote:
| I have a 3070 on X and it has been great.
| levkk wrote:
| Same setup here. Multiple displays don't work well for me.
| One of the displays doesn't often get detected after
| resuming screen saver.
| llmblockchain wrote:
| I have two monitors connected to the 3070 and it works
| well. The only issue I had was suspending, the GPU would
| "fall of the bus" and not get its power back when the PC
| woke up. I had to add the kernel line "pcie_aspm=off" to
| prevent the GPU from falling asleep.
|
| So... not perfect, but it works.
| josephg wrote:
| Huh. I'm using 2 monitors connected to a 4090 on Linux
| mint - which is still using X11. It works flawlessly,
| including DPI scaling. Wake from sleep is fine too.
|
| I haven't tried wayland yet. Sounds like it might be time
| soon given other comments in this thread.
| misterbishop wrote:
| this is resolved in 555 (currently running 555.58.02). my
| asus zephyrus g15 w/ 3060 is looking real good on Fedora 40.
| there's still optimizations needed around clocking, power,
| and thermals. but the graphics presentation layer has no
| issues on wayland. that's with hybrid/optimus/prime
| switching, which has NEVER worked seamlessly for me on any
| laptop on linux going back to 2010. gnome window animations
| remain snappy and not glitchy while running a game. i'm
| getting 60fps+ running baldurs gate 3 @ 1440p on the low
| preset.
| robviren wrote:
| Had similar experience with my Legion 5i 3070 with Wayland
| and Nvidia 555, but my HDMI out is all screwed up now of
| course. Working on 550. One step forward and one step back.
| bcrescimanno wrote:
| The 555 version is the current version. It was officially
| released on June 27.
|
| https://www.phoronix.com/news/NVIDIA-555.58-Linux-Driver
| JasonSage wrote:
| In defense of the parent, upcoming can still be a relative
| term, albeit a bit misleading. For example: I'm running the
| 550 drivers still because my upstream nixos-unstable
| doesn't have 555 for me yet.
| mepian wrote:
| Yep, I'm on openSUSE Tumbleweed, and it's not rolled out
| there yet. I would rather wait than update my drivers
| out-of-band.
| SushiHippie wrote:
| The versions that nixos provides are based on the files
| in this repo
|
| https://github.com/aaronp24/nvidia-versions
|
| See: https://github.com/NixOS/nixpkgs/blob/9355fa86e6f274
| 22963132...
|
| You could also opt to use the latest driver instead of
| stable: https://nixos.wiki/wiki/Nvidia
| mananaysiempre wrote:
| > nixos-unstable doesn't have 555
|
| Version 555.58.02 is under "latest" in nixos-unstable as
| of about three weeks ago[1]. (Somebody should check with
| qyliss if she knows the PR tracker is dead... But the
| last nixos-unstable bump was two days ago, so it's
| there.)
|
| [1] https://github.com/NixOS/nixpkgs/commit/4e15c4a8ad30c
| 02d6c26...
| anon291 wrote:
| I've literally never had an issue in decades of using NVIDIA
| and linux. They're closed source, but the drivers work very
| consistently for me. NVIDIA's just the only option if you want
| something actually good and to run ML workloads as well.
| sqeaky wrote:
| > but the drivers work very consistently for me
|
| The problem with comments like this is that you never know if
| you will be me or you on your graphics card or laptop.
|
| I have tried nvidia a few times and kept getting burnt. AMD
| just works. I don't get the fastest ML machine, but I am just
| a tinkerer there and OpenCL works fine for my little toy apps
| and my 7900XTX blazes through every wine game.
|
| If you need it professionally than you need it, warts an all.
| For any casual user that 10% extra gaming performance needs
| to weighed against reliability.
| Workaccount2 wrote:
| It also depends heavily on the user.
|
| A mechanic might say "This car has never given me a
| problem" because the mechanic doesn't consider cleaning an
| idle bypass circuit or adjusting valve clearances to be a
| "problem". To 99% percent of the population though, those
| are expensive and annoying problems because they have no
| idea what those words even mean, much less the ability to
| troubleshoot, diagnose, and repair.
| chasil wrote:
| If you use a search engine for "Torvalds Nvidia" you will
| discern a certain attitude towards Nvidia as a
| corporation and its products.
|
| This might provide you a suggestion that alternate
| manufacturers should be considered.
|
| I have confirmed this to be the case on Google and Bing,
| so DuckDuckGo and Startpage will also exhibit this
| phenomena.
| lyu07282 wrote:
| a lot has probably to do with not really understanding
| their distributions package manager and lkms
| specifically, I also always suspected that most Linux
| users don't know if they are using Wayland or X11 and the
| issues they had were actually Wayland specific ones they
| wouldn't have with Nvidia/x11 and come to think of it,
| how would they even know if it's a GPU driver issue in
| the first place? Guess I'm the mechanic in your analogy.
| sqeaky wrote:
| When I run Gentoo or Arch, I know. But when I run Ubuntu
| or Fedora, should I have needed to know?
|
| On plenty of distros "I want to install it and forget
| about is reasonable" and on both Gentoo and Ubuntu I have
| rebooted from a working system into a system where the
| display stopped working, at least on Gentoo I was ready
| because I broke it somehow.
| bobajeff wrote:
| I did when my card stopped being supported by all the distros
| because it was too old while the legacy driver didn't fully
| work the same.
| l33tman wrote:
| Same here, been using the nvidia binary drivers on a dozen
| computers with various other HW and distros for decades with
| never any problems whatsoever.
| pizza234 wrote:
| Up to a couple of years ago, before permanently moving to AMD
| GPUs, I couldn't even boot Ubuntu with an Nvida GPU. This was
| because Ubuntu booted by default with Nouveau, which didn't
| support a few/several series (I had at least two different
| series).
|
| The cards worked fine with binary drivers once the system was
| installed, but AFAIR, I had to integrate the binary driver
| packages in the Ubuntu ISO in order to boot.
|
| I presume that now, the situation is much better, but
| necessiting binary drivers can be a problem in itself.
| art0rz wrote:
| I've been running Arch with KDE under Wayland on two different
| laptops both with NVIDIA GPUs using proprietary drivers for
| years and have not run into issues. Maybe I'm lucky? It's been
| flawless for me.
| lyu07282 wrote:
| The experiences always vary quite a lot, it depends so much
| on what you do with it. For example discord doesn't support
| screen sharing with Wayland, it's just one small example but
| those can add up over time. Another example is display
| rotation which was broken in kde for a long time (recently
| fixed).
| green-salt wrote:
| Whatever pop_os uses has been quite stable for my 4070.
| tormeh wrote:
| Pop uses X by default because of Nvidia.
| segmondy wrote:
| plug, install then play, I got 3 different Nvidia GPU sets and
| all running without any issue, nothing crazy to do but follow
| installation instructions.
| DaoVeles wrote:
| I have never had an issue with them. That said I typically go
| mid range on cards so they are usually hardened architecture
| due to a year or two of being in the high end.
| mathfailure wrote:
| Depends on the version of drivers: 550 version results into
| black screen (you have to kill and restart X server) after
| waking up from sleep. 535 version doesn't have this bug. Don't
| know about 555.
|
| Also tearing is a bitch. Still. Even with
| ForceCompositionPipeline.
| drdaeman wrote:
| 3090 owner here.
|
| Wayland is even worse mess than it normally is. Used to flicker
| real bad before 555.58.02, less so with the latest driver - but
| still has some glitches with games. A bunch of older Electron
| apps still fail to render anything and require hardware
| acceleration disabled. I gave up trying to make it all work -
| can't get rid of all the flicker and drawing issues, plus
| Wayland seems to be a real pain in the ass with HiDPI displays.
|
| X11 sort of works, but I had to entirely disable DPMS or one of
| my monitors never comes back online after going to sleep. I
| thought it was my KVM messing up, but that happened even with a
| direct connection... no idea what's going on there.
|
| CUDA works fine, save for the regular version compatibility
| hiccups.
| brrrrrm wrote:
| Kernel is an overloaded term for GPUs. This is about the linux
| kernel
| karamanolev wrote:
| "... Linux GPU Kernel Modules" is pretty unambiguous to me.
| brrrrrm wrote:
| Yep the title was updated.
| berkeleyjunk wrote:
| As someone who is pretty skeptical and reads the fine print, I
| think this is a good move and I really do not see a downside
| (other than the fact that this probably strengthens the nVidia
| monoculture).
| vlovich123 wrote:
| AFAIK I believe all they did was move the closed source user
| space driver code to their opaque firmware blob leaving a thin
| shim in the kernel.
|
| In essence I don't believe that much has really changed here.
| stkdump wrote:
| But the firmware runs directly on the hardware, right? So
| they effectively rearchitected their system to move what used
| to be 'above' the kernel to 'below' the kernel, which seems
| like a huge effort.
| vlovich123 wrote:
| It's some effort but I bet they added a classical serial
| CPU to run the existing code. In fact, [1] suggests that's
| exactly what they did. I suspect they had other reasons to
| add the GSP so the amortized cost of moving the driver code
| to firmware was actually not that large all things
| considered and in the long term reduces their costs (eg
| they reduce the burden further of supporting multiple OSes,
| they can improve performance further theoretically, etc
| etc)
|
| [1] https://download.nvidia.com/XFree86/Linux-x86_64/525.78
| .01/R...
| p_l wrote:
| That's exactly what happened - Turing microarchitecture
| brought in new[1] "GSP" which is capable enough to run
| the task. Similar architecture happens AFAIK on Apple
| M-series where the GPU runs its own instance of RTOS
| talking with "application OS" over RPC.
|
| [1] Turing GSP is not the first "classical serial CPU" in
| nvidia chips, it's just first that has enough juice to do
| the task. Unfortunately without recalling the name of the
| component it seems impossible to find it again thanks to
| search results being full of nvidia ARM and GSP pages...
| mepian wrote:
| >the name of the component
|
| Falcon?
| p_l wrote:
| THANK YOU, that was the name I was forgetting :)
|
| here's[1] a presentation from nvidia regarding (unsure if
| done or not) plan for replacing Falcon with RISC-V, [2]
| suggests the GSP is in fact the "NV-RISC" mentioned in
| [1]. Some work on reversing Falcon was apparently done
| for Switch hacking[3]?
|
| [1] https://riscv.org/wp-
| content/uploads/2016/07/Tue1100_Nvidia_... [2]
| https://www.techpowerup.com/291088/nvidia-unlocks-gpu-
| system... [3] https://github.com/vbe0201/faucon
| knotimpressed wrote:
| Would you happen to have a source or any further readings
| about Apple M-series GPUs running their own RTOS
| instance?
| imtringued wrote:
| Why? It should make it much easier to support Nvidia GPUs
| on Windows, Linux, Arm/x86/RISC-V and more OSes with a
| single firmware codebase per GPU now.
| stkdump wrote:
| Yes makes sense, in the long run it should make their
| life easier. I just suspect that the move itself was a
| big effort. But probably they can afford that nowadays.
| bradyriddle wrote:
| I remember Nvidia getting hacked pretty bad a few years ago.
| IIRC, the hackers threatened to release everything they had
| unless they open sourced their drivers. Maybe they got what they
| wanted.
|
| [0] https://portswigger.net/daily-swig/nvidia-hackers-
| allegedly-...
| nicce wrote:
| Kernel modules are not user-space drivers which are still
| proprietary.
| porphyra wrote:
| Much of the black magic has been moved from the drivers to
| the firmware anyway.
| bradyriddle wrote:
| Ooops. Missed that part.
|
| Re-reading that story is kind of wild. I don't know how
| valuable what they allegedly got would be (silicon, graphics
| and chipset files) but the hackers accused Nvidia of 'hacking
| back' and encrypting their data.
|
| Reminds me of a story I heard about Nvidia hiring a private
| military to guard their cards after entire shipments started
| getting 'lost' somewhere in asia.
| dralley wrote:
| I doubt it. It's probably a matter of constantly being prodded
| by their industry partners (i.e. Red Hat), constantly being
| shamed by the community, and reducing the amount of maintenance
| they need to do to keep their driver stack updated and working
| on new kernels.
|
| The meat of the drivers is still proprietary, this just allows
| them to be loaded without a proprietary kernel module.
| p_l wrote:
| I suspect it's mainly the reduced maintenance and reduction
| of workload needed to support, especially with more platforms
| coming to be supported (not so long ago there was no ARM64
| nvidia support, now they are shipping their own ARM64
| servers!)
|
| What really changed the situation is that Turing architecture
| GPUs bring new, more powerful management CPU, which has
| enough capacity to essentially run the OS-agnostic parts of
| driver that used to be provided as blob on linux.
| knotimpressed wrote:
| Am I correct in reading that as Turing architecture cards
| include a small CPU on the GPU board, running parts of the
| driver/other code?
| kabes wrote:
| It's hard to believe one of the highest valued companies in
| the world cares about being shamed for not having open source
| drivers.
| nailer wrote:
| Having products that require a bunch of extra work due to
| proprietary drivers, especially when their competitors
| don't require that work, is not good.
| commodoreboxer wrote:
| They care when it affects their bottom line, and customers
| leaving for the competition does that.
|
| I don't know if that's what's happening here, honestly, but
| you're right that they don't care about being shamed, but
| building a reputation of being hard to work with and
| target, especially in a growing market like Linux (still
| tiny, but growing nonetheless, and becoming significantly
| more important in the areas where non-gaming GPU use is
| concerned) can start to erode sales and B2B relationships,
| and the latter particularly if you make the programmers and
| PMs hate using your products.
| bryanlarsen wrote:
| > in a growing market like Linux
|
| Isn't Linux 80% of their market? ML et al is 80% of their
| sales, and ~99% of that is Linux.
| fngjdflmdflg wrote:
| True, although note that the Linux market itself is
| increasing in size due to ML. Maybe "increasingly
| dominant market" is a better phrase here.
| enoeht wrote:
| didn't they say that many times before?
| vlovich123 wrote:
| Not sure but with the Turing series they support having a
| cryptographically signed binary blob that they load on the GPU.
| So before where their kernel driver was a thin shim for the
| user space driver, now it's a thin shim for the black box
| firmware loaded on the GPU
| creata wrote:
| Huh. Sway and Wayland was such a nightmare on Nvidia that it
| convinced me to switch to AMD. I wonder if it's better now.
|
| (IIRC the main issue was
| https://gitlab.freedesktop.org/xorg/xserver/-/issues/1317 , which
| is now complete.)
| snailmailman wrote:
| Better as of extremely recently. Explicit sync fixes most of
| the issues with flickering that I've had on Wayland. I've been
| using the latest (beta?) driver for a while because of it.
|
| I'm using Hyprland though so explicit sync support isn't
| _entirely_ there for me yet. It's actively being worked on. But
| in the last few months it's gotten a lot better
| JasonSage wrote:
| > Better as of extremely recently.
|
| Yup. Anecdotally, I see a lot of folks trying to run
| wine/games on Wayland reporting flickering issues that are
| gone as of version 555, which is the most recent release save
| for 560 coming out this week. It's a good time to be on the
| bleeding edge.
| hulitu wrote:
| You can always use X11. /s
| asyx wrote:
| I think it's X11 stuff that is using Vulkan for rendering
| that is still flickering in 555. This probably affects
| pretty much all of Proton / Wine gaming.
| joecool1029 wrote:
| It's buggy still with sway on nvidia. I really thought the 555
| driver would wrinkle out last of the issues but it still has
| further to go. Switched to kde plasma 6 on wayland since then
| and it's been great, not buggy at all.
| Animats wrote:
| NVidia revenue is now 78% from "AI" devices.[1] NVidia's market
| cap is now US$2.92 trillion. (Yes, trillion.) Only Apple and
| Microsoft can beat that. Their ROI climbed from about 10% to 90%
| in the last two years. That growth has all been on the AI side.
|
| Open-sourcing graphics drivers may indicate that NVidia is moving
| away from GPUs for graphics. That's not where the money is now.
|
| [1] https://www.visualcapitalist.com/nvidia-revenue-by-
| product-l...
|
| [2] https://www.macrotrends.net/stocks/charts/NVDA/nvidia/roi
| joe_the_user wrote:
| Well, Nvidia seems to be claiming in the article that this is
| everything, not just graphics drivers: _" NVIDIA GPUs share a
| common driver architecture and capability set. The same driver
| for your desktop or laptop runs the world's most advanced AI
| workloads in the cloud. It's been incredibly important to us
| that we get it just right."_
|
| And _For cutting-edge platforms such as NVIDIA Grace Hopper or
| NVIDIA Blackwell, you must use the open-source GPU kernel
| modules. The proprietary drivers are unsupported on these
| platforms._ (These are two most advanced NVIDIA architectures
| currently)
| Animats wrote:
| That's interesting. I've been expecting the AI cards to
| diverge more from the graphics cards. AI doesn't need
| triangle fill, Z-buffering, HDMI out, etc. 16 bit 4x4
| multiply/add units are probably enough. What's going on in
| that area?
| orbital-decay wrote:
| It indicates nothing; they started it a few years ago, before
| that. They just transferred the most important parts of their
| driver to the (closed source) firmware, to be handled by the
| onboard ARM CPU, and open sourced the rest.
| floam wrote:
| NVIDIA Transitions Fully Towards Open-Source GPU Kernel Modules
|
| or
|
| NVIDIA Transitions Towards Fully Open-Source GPU Kernel Modules?
| j4hdufd8 wrote:
| haven't read it but probably the former
| throwadobe wrote:
| "towards" basically negates the "fully" before it for all
| real intents and purposes
| slashdave wrote:
| Not much point in a "partially" open-source kernel module.
| floam wrote:
| But "fully towards" is pretty ambiguous, like an entire
| partial implementation.
|
| Anyhow I read the article, I think they're saying fully as in
| exclusively, like there eventually will not be both a closed
| source and open source driver co-maintained. So "fully open
| source" does make more sense. The current driver situation IS
| partially open source, because their offerings currently
| include open and closed source drivers and in the future the
| closed source drivers may be deprecated?
| einpoklum wrote:
| See my answer. It's not going to be fully-open-source
| drivers, it's rather that all drivers will have open-source
| kernel modules.
| pluto_modadic wrote:
| damn, only for new GPUs.
| mynameisvlad wrote:
| For varying definitions of "new". It supports Turing and up,
| which was released in 2018 with the 20xx line. That's two
| generations back at this point.
| sillywalk wrote:
| From the github repo[0]:
|
| Most of NVIDIA's kernel modules are split into two components:
| An "OS-agnostic" component: this is the component of each kernel
| module that is independent of operating system. A
| "kernel interface layer": this is the component of each kernel
| module that is specific to the Linux kernel version and
| configuration.
|
| When packaged in the NVIDIA .run installation package, the OS-
| agnostic component is provided as a binary:
|
| [0] https://github.com/NVIDIA/open-gpu-kernel-modules
| p_l wrote:
| That was the "classic" drivers.
|
| The new open source ones effectively move majority of the OS-
| agnostic component to run as blob on-GPU.
| arghwhat wrote:
| Not quite - it moves some logic to the GSP firmware, but the
| user-space driver is still a significant portion of code.
|
| The exciting bits there is the work on NVK.
| p_l wrote:
| Yes, I was not including userspace driver in this, as a bit
| "out of scope" for the conversation :D
| benjiweber wrote:
| I wonder if we'll ever get hdcp on nvidia. As much as I enjoy
| 480p video from streaming services.
| smcleod wrote:
| So does this mean actually getting rid of the binary blobs of
| microcode that are in their current 'open' drivers?
| p_l wrote:
| No, it means the blob from the "closed" drivers is moved to run
| on GSP.
| risho wrote:
| does this mean you will be able to use NVK/Mesa and CUDA at the
| same time? The non mesa proprietary side of nvidia's linux
| drivers are such a mess and NVK is improving by the day, but I
| really need cuda.
| john2x wrote:
| Maybe that's one way to retain engineers who are effectively
| millionaires.
| magicloop wrote:
| Remember that time when Linus looked at the camera and gave
| Nvidia the finger. Has that time now passed? Is it time to
| reconcile? Or are there still some gotchas?
| jcalvinowens wrote:
| Throwing the tarball over the wall and saying "fetch!" is
| meaningless to me. Until they actually contribute a driver to the
| upstream kernel, I'll be buying AMD.
| xyst wrote:
| Nvidia has finally realize they couldn't write drivers for their
| own hardware, especially for Linux.
|
| Never thought I would see the day.
| TeMPOraL wrote:
| Suddenly they went from powering gaming to being the winners of
| the AI revolution; AI is Serious Cloud Stuff, and Serious Cloud
| Stuff means Linux, so...
| shmerl wrote:
| That's not upstream yet. But they supposedly showed some
| interesting in nova too.
| asaiacai wrote:
| I really hope this makes it easier to install/upgrade NVIDIA
| drivers on Linux. It's a nightmare to figure out version
| mismatches between drivers, utils, container-runtime...
| einpoklum wrote:
| From my limited experience with their open-sourcing of kernel
| modules so far: It doesn't make things easier; but - the silver
| lining is that, for the most part, it doesn't make installation
| and configuration harder! Which is no small thing actually.
| einpoklum wrote:
| The title of this statement is misleading:
|
| NVIDIA is not transitioning to open-source drivers for its GPUs;
| most or all user-space parts of the drivers (and most importantly
| for me, libcuda.so) are closed-source; and as I understand from
| others, most of the logic is now in a binary blob that gets sent
| to the GPU.
|
| Now, I'm sure this open-sourcing has its uses, but for people who
| want to do something like a different hardware backend for CUDA
| with the same API, or to clear up "corners" of the API semantics,
| or to write things in a different-language without going through
| the C API - this does not help us.
| qalmakka wrote:
| Well, it is something, even if it's still only the kernel module,
| and it will be probably never upstreamed anyway.
___________________________________________________________________
(page generated 2024-07-17 23:02 UTC)