Live data from Hacker News

NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules

developer.nvidia.com

171–180 of 259 posts

Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules

#171
There is little meaning for NVIDIA to open-source only the driver portion of their cards, since they heavily rely on proprietary firmware and userspace lib (most important!) to do the real job. Firmware is a relatively small issue - this is mostly same for AMD and Intel, since encapsulation reduces work done on driver side and open-sourcing firmware could allow people to do some really unanticipated modification which might heavily threaten even commercial card sale. Nonetheless at least for AMD they still keep a fair share of work done by driver compared to Nvidia. Userspace library is the worst problem, since they handle a lot of GPU control related functionality and graphics API, which is still kept closed-source.

The best thing we can hope is improvement on NVK and RedHat's Nova Driver can put pressure on NVIDIA releasing their user space components.

Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules

#172
post #156
post #8

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.)

why switch to amd and not just switch to X? :D

once you go Wayland you usually don’t go back :)

Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules

#173

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.

You can just use Nouveau and NVK for that if you just need workstation graphics (and the open-gpu-modules source code/separate GSP release has been a big uplift to Nouveau too, at least.)

Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules

#174
post #21

Earlier quoted context omitted.

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.

Nvidia has historically given zero fucks about the opinions of their partners. So my guess is it's to do with LLMs. They are all in on AI, and having more of their code be part of training sets could make tools like ChatGPT/Claude/Copilot better at generating code for Nvidia GPUs.

Yup. nVidia wants those fat compute center checks to keep coming in. It's an unsaturated market, unlike gaming consoles, home gaming PCs, and design/production workstations. They got a taste of that blockchain dollar, and now AI looks to double down on the demand.

The best solution is to have the industry eat their dogfood.

Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules

#175

They know CUDA monopoly won't last forever.

CUDA lives in userspace; this kernel driver release does not contain any of that. It's still very useful to release an open source DKMS driver, but this doesn't change anything at all about the CUDA situation.

Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules

#176
Thank You Nvidia hacker! You did it! The Lapasu$ team threaten a few years back that if nvidia is not going to release nvidia opensource they are gonna release their code. That lead nvidia to releasing first kernel opensource module in a few months later but it was quite incomplete. Now it seems they are opensourcing fully more.

Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules

#177

Earlier quoted context omitted.

> 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/4e15c4a8ad30c02d6c26...

`nvidia-smi` shows that my driver version is 550.78. I ran `nixos-rebuild switch --upgrade` yesterday. My nixos channel is `nixos-unstable`. Do you know something I don't? I'd love to be on the latest version. I should have written my post better, it implies that 555 does not exist in nixpkgs, which I never meant. There's certainly a phrasing that captures what I'm seeing more accurately.

I did not mean to chastise you or anything, just to suggest you could be able to have a newer driver if you had missed the possibility.

The thing is, AFAIU, NVIDIA has several release channels for their Linux driver[1] and 555 is not (yet?) the "production" one, which is what NixOS defaults to (550 is). If you want a different degree of freshness for your NVIDIA driver, you need to say so explicitly[2]. The necessary incantation should be

  hardware.nvidia.package = config.boot.kernelPackages.nvidiaPackages.latest;
This is somewhat similar to how you get a newer kernel by setting boot.kernelPackages to linuxPackages_latest, for example, if case you've ever done that.

[1] https://www.nvidia.com/en-us/drivers/unix/

[2] https://nixos.wiki/wiki/Nvidia

Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules

#178
post #154

Earlier quoted context omitted.

As well isolated as anything else on the bus. So you better actually use IOMMU

Ah, yes, the magical IOMMU controller, that everybody just assumes to be implemented perfectly across the board. I'm expecting this to be like Hyperthreading, where we find out 20 years later, that the feature was faulty/maybe_bugdoored since inception in many/most/all implementations. Same thing with USB3/TB-controllers, NPUs, etc that everybody just expects to be perfectly implemented to spec, with flawless firmwar…

It's not perfect or anything, but it's usually a step up[1], and the funniest thing is that GPUs generally had less of ... "interesting" compute facilities to jump over from, just easier to access usually. My first 64 bit laptop, my first android smartphone, first few iPhones, had more MIPS32le cores with possible DMA access to memory than the main CPU cores, and that was just counting one component of many (the wifi chip).

Also, Hyperthreading wasn't itself faulty or "bugdoored". The tricks necessary to get high performance out of CPUs were, and then there was intel deciding to drop various good precautions in name of still higher single core performance.

Fortunately, after several years, IOMMU availability becomes more common (current laptop I'm writing this on has proper separate groups for every device it seems)

[1] There's always the OpenBSD of navel gazing about writing "secure" C code, becoming slowly obsolescent thanks to being behind in performance and features, and ultimately getting pwned because your C focus and not implementing "complex" features helping mitigate access results in pwnable SMTPd running as root.

Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules

#179
post #154

Earlier quoted context omitted.

How well isolated is this secondary computer? Do we have reason to fear the proprietary software running on it?

As well isolated as anything else on the bus. So you better actually use IOMMU

> you better actually use IOMMU

Is this feature commonly present on PC hardware? I've only ever read about it in the context of smartphone security. I've also read that nvidia doesn't like this sort of thing because it allows virtualizing their cards which is supposed to be an "enterprise" feature.

Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules

#180
post #156

Earlier quoted context omitted.

why switch to amd and not just switch to X? :D

once you go Wayland you usually don’t go back :)

I tested wayland for a while to see what the hype is about. No uoside lits of small workflows broken. Back to Xorg it was.
Post reply on HN