Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules

developer.nvidia.com

Post reply on HN
Print view View original

211–220 of 259 posts

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

#211

Post by postcert »

Fr0styMatt88 wrote: post #142
JasonSage wrote: post #116

Earlier quoted context omitted.

That's interesting, maybe it's hardware-dependent? I'm doing nixos + KDE + Wayland and I've had almost no issues in day-to-day usage and productivity. I agree with you that there's a lot of bleeding. Linux is nicer than it used to be and there's less fiddling required to get to a usable base, but still plenty of fiddling as you get into more niche usage, especially when it involves any GPU hardware/software. Yet some…

Yeah it’s pretty awesome overall. I think the issues are from a few things on my end: - I’ve upgraded through a few iterations starting with Plasma 6, so my dotfiles might be a bit wonky. I’m not using Home Manager so my dotfiles are stateful. - Could be very particular to my dock setup as I have two docks + one of the clock widgets. - Could be the particular wallpaper I’m using (it’s one of the dynamic ones that com…

I've been having a similar flakiness with plasma on Nixos (proprietary + 3070 as well). Sadly can't say whether it did{n't} happen on another distro as I last used Arch around the v535 driver.

I found it funny how silently it would fail at times. After coming out of a game or focusing on something I'd scratch my head as to where did the docks/background went. I'd say you're lucky in that it recovered itself, generally I needed to run `plasmashell` in the alt+f2 run prompt.

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

#212

Post by JasonSage »

mananaysiempre wrote: post #177
JasonSage wrote: post #105

Earlier quoted context omitted.

`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…

I had this configuration but was lacking a flake update to move my nixpkgs forward despite the channel, which I can understand much better looking back.

Thanks for the additional info, this HM thread has helped me quite a bit.

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

#213

Post by postcert »

zxexz wrote: post #124
JasonSage wrote: post #76

Earlier quoted context omitted.

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.

I love NixOS, and the nvidia-x11 package is truly wonderful and captures so many options. But having such a complex package makes updating and regression testing take time. For ML stuff I ended up using it as the basis for an overlay, and ripping out literally everything I don’t need, which makes it a matter of minutes usually to make the changes requires to upgrade when a new driver is released I’m running completel…

I was going to say specialisations might be useful for you to keep a previous driver version around for testing but you might be past that point!

Having the ability to keep alternate configurations for $previous_kernel and $nvidia_stable have been super helpful in diagnosing instead of rolling back.

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

#214

Post by Arch-TK »

josefx wrote: post #140
nailer wrote: post #65

Earlier quoted context omitted.

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.

The biggest chunk of that "extra work" would be installing Linux in the first place, given that almost everything comes with Windows out of the box. An additional "sudo apt install nvidia-drivers" isn't going to stop anyone who already got that far.

Tainted kernel. Having to sort out secure boot problems caused by use of an out of tree module. DKMS. Annoying weird issues with different kernel versions and problems running the bleeding edge.

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

#215

Post by johnny22 »

doix wrote: post #191
asyx wrote: post #57

Earlier quoted context omitted.

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.

Any specific examples that you know should be broken? I am on X11 with 555 drivers and an nvidia gpu. I don't have any flickering when I'm gaming, it's actually why I stay on X11 instead of transitioning to wayland.

They are probably talking about running the game in a wayland session via xwayland, since wine's wayland driver is not part of proton yet.

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

#216

Post by chasil »

Dylan16807 wrote: post #118
chasil wrote: post #53

Earlier quoted context omitted.

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.

An opinion on support from over ten years ago is not a very strong suggestion.

Your problem there is that both search engines place this image and backstory at the top of the results, so neither Google nor Bing agree with any of you.

If you think they're wrong, be sure to let them know.

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

#217

Post by Arch-TK »

vetinari wrote: post #203
bornfreddy wrote: post #148

Earlier quoted context omitted.

I know that was a joke, but - as someone who is still on X, what am I missing? Any practical advantages to using Wayland when using a single monitor on desktop computer?

Even that single monitor can be hidpi, vrr or hdr (this one is still wip).

I have a 165 DPI monitor. This honestly just works with far less hassle on X. I don't have to listen to anyone try to explain to me how fractional scaling doesn't make sense (real explanation for why it wasn't supported). I don't have to deal with some silly explanation for why XWayland applications just can't be non-blurry with a fractional or non-1 scaling factor. I can just set the DPI to the value I calculated and things work in 99% of cases. In 0.9% of the remaining cases I need to set an environment variable or pass a flag to fix a buggy application and in the 0.1% of cases I need to make a change to the code.

VRR has always worked for me on single monitor X. I use it on my gaming computer (so about twice a year).

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

#218

Post by p_l »

stragies wrote: post #201
p_l wrote: post #178

Earlier quoted context omitted.

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 wif…

All fine and well, but I always come back to "If I were a manufacturer/creator of some work/device/software, that does something in the plausible realm of 'telecommunication', how do make sure, that my product can always comply with https://en.wikipedia.org/wiki/Lawful_interception requests? Allow for ingress/egress of data/commands at as low a level as possible!" So as a chipset creator company director it would see…

If your product is supposed to comply with Lawful Interception, you're going to implement proper LI interfaces, not leave bullshit DMA bugs in.

The very point of Lawful Interception involves explicit, described interfaces, so that all parties involved can do the work.

The systems with LI interfaces also often end up in jurisdictions that simultaneously put high penalties on giving access to them without specific authorizations - I know, I had to sign some really interesting legalese once due to working in environment where we had to balance both Lawful Interception, post-facto access to data, and telecommunications privacy laws.

Leaving backdoors like that is for Unlawful Interception, and the danger of such approaches is greatly exposed in form of Chinese intelligence services exploiting NSA backdoor in Juniper routers (infamous DRBG_EC RNG)

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

#219

Post by p_l »

brendank310 wrote: post #187
matheusmoreira wrote: post #179

Earlier quoted context omitted.

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

Relatively common nowadays. It used to be delineated as a feature in Intel chips as part of their vPro line, but I think it’s baked in. Generally an IOMMU is needed for performant PCI passthrough to VMs, and Windows uses it for DeviceGuard which tries to prevent DMA attacks.

Seems to me that Zen 4 has no issues at all, but bridges/switches require additional interfaces to further fan-out access controls.

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

#220

Post by slashdave »

einpoklum wrote: post #90
floam wrote: post #84

Earlier quoted context omitted.

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…

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.

You can argue against proprietary firmware, but is this all that different from other types of devices?
Post reply on HN