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.
NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules
171–180 of 259 posts
Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules
#172Huh. 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
Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules
#173Throwing 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.
Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules
#174Earlier 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.
The best solution is to have the industry eat their dogfood.
Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules
#175They know CUDA monopoly won't last forever.
Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules
#176Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules
#177Earlier 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.
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.Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules
#178Earlier 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…
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
#179Earlier 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
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.