Live data from Hacker News

NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules

developer.nvidia.com

231–240 of 259 posts

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

#231
post #216

Earlier quoted context omitted.

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.

What torvalds is complaining about is absolutely true, but the problem is that most users do not give a shit about those issues. Torvalds disagreement wasn't about bugs in-, or complains about the quality of the proprietary driver, he complained about nvidias lack of open source contributions and bad behavior towards the kernel developer community. But users don't care if they run a proprietary driver as long as it w…

No.

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

#233

Earlier quoted context omitted.

I really don't know where this crap about "Moving everything to the firmware" is coming from. The kernel part of the nvidia driver has always been small, and this is the only thing they are open-sourcing (they have been announcing it for months now......). The immense majority of the user-space driver is still closed and no one has seen any indications that this may change. I see no indications either that either nvi…

https://lwn.net/Articles/953144/ > Recently, though, the company has rearchitected its products, adding a large RISC-V processor (the GPU system processor, or GSP) and moving much of the functionality once handled by drivers into the GSP firmware. The company allows that firmware to be used by Linux and shipped by distributors. This arrangement brings a number of advantages; for example, it is now possible for the ke…

>> I see no indications either that either nvidia nor any of the rest of the manufacturers has moved any respectable amount of functionality to the firmware.

Someone who believes this could easily prove that they are correct by "simply" taking their 4090 and documenting all its functionality, as was done with the [7900 xtx](https://github.com/geohot/7900xtx).

You can't say "I see no indications/evidence" unless you have proven that there is no evidence, no?

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

#234
post #233

Earlier quoted context omitted.

https://lwn.net/Articles/953144/ > Recently, though, the company has rearchitected its products, adding a large RISC-V processor (the GPU system processor, or GSP) and moving much of the functionality once handled by drivers into the GSP firmware. The company allows that firmware to be used by Linux and shipped by distributors. This arrangement brings a number of advantages; for example, it is now possible for the ke…

>> I see no indications either that either nvidia nor any of the rest of the manufacturers has moved any respectable amount of functionality to the firmware. Someone who believes this could easily prove that they are correct by "simply" taking their 4090 and documenting all its functionality, as was done with the [7900 xtx]( https://github.com/geohot/7900xtx ). You can't say "I see no indications/evidence" unless you…

so basically “if you really think there’s no proof of a positive claim, then you won’t mind conclusively proving the negation”?

no, that’s not how either logical propositions or burden of proof works

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

#235

Earlier quoted context omitted.

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?

Other device manufacturers with proprietary drivers don't engage in publicity stunts to make it sound like their drivers are FOSS or that they embrace FOSS (or just OSS).

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

#236

Earlier quoted context omitted.

It is meaningful because, as you note, it enables a fully opensource userspace driver. Of course the firmware is still proprietary and it increasingly contains more and more logic.

Doesn't seem like a bad tradeoff so long as the proprietary stuff is kept completely isolated with no access to any other parts of my system.

Personally, I somewhat wonder about that. The firmware (proprietary) which runs on the gpu seems like it'll have access to do things over the gpu PCIe bus, including read system memory, and access other devices (including network gear). Reading memory of remote hosts (ie RDMA) is also a thing which Nvidia gpus can do.

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

#237

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

It is meaningful because, as you note, it enables a fully opensource userspace driver. Of course the firmware is still proprietary and it increasingly contains more and more logic.

the open kernel driver also fundamentally breaks the limitation about geforce gpus not being licensed for use in the datacenter. that provision is a driver provision and CUDA does not follow the same license as the driver... really the only significant limitation is that you aren't allowed to use the CUDA toolkit to develop for non-NVIDIA hardware, and some license notice requirements if you redistribute the sample projects or other sample sourcecode. and yeah they paid to develop it, it's proprietary source code, that's reasonable overall.

https://docs.nvidia.com/cuda/eula/index.html

ctrl-f "datacenter": none

so yeah, I'm not sure where the assertion of "no progress" and "nothing meaningful" and "this changes nothing" come from, other than pure fanboyism/anti-fans. before you couldn't write a libre CUDA userland even if you wanted to - the kernel side wasn't there. And now you can, and this allows retiming and clock-up of supported gpus even with nouveau-style libre userlands. Which of course don't grow on trees, but it's still progress.

honestly it's kinda embarrassing that grown-ass adults are still getting their positions from what is functionally just some sick burn in a 2004 viral video or whatever, to the extent they actively oppose the company moving in the direction of libre software at all. but I think with the "linus torvalds" citers, you just can't reason those people out of a position that they didn't reason themselves into. Not only is it an emotionally-driven (and fanboy-driven) mindset, but it's literally not even their own position to begin with, it's just something they're absorbing from youtube via osmosis.

Apple debates and NVIDIA debates always come down to the anti-fans bringing down the discourse. It's honestly sad. https://paulgraham.com/fh.html

it also generally speaks to the long-term success and intellectual victory of the GPL/FSF that people see proprietary software as somehow inherently bad and illegitimate... even when source is available, in some cases. Like CUDA's toolchain and libraries/ecosystem is pretty much the ideal example of a company paying to develop a solution that would not otherwise have been developed, in a market that was (at the time) not really interested until NVIDIA went ahead and proved the value. You don't get to ret-con every single successful software project as being retroactively open-source just because you really really want to run it on a competitor's hardware. But people now have this mindset that if it's not libre then it's somehow illegitimate.

Again, most CUDA stuff is distributed as source, if you want to modify and extend it you can do so, subject to the terms of the CUDA license... and that's not good enough either.

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

#238

Earlier quoted context omitted.

Doesn't seem like a bad tradeoff so long as the proprietary stuff is kept completely isolated with no access to any other parts of my system.

Personally, I somewhat wonder about that. The firmware (proprietary) which runs on the gpu seems like it'll have access to do things over the gpu PCIe bus, including read system memory, and access other devices (including network gear). Reading memory of remote hosts (ie RDMA) is also a thing which Nvidia gpus can do.

Is that not solvable using an IOMMU (assuming hardware that has one)?

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

#239

Earlier quoted context omitted.

Personally, I somewhat wonder about that. The firmware (proprietary) which runs on the gpu seems like it'll have access to do things over the gpu PCIe bus, including read system memory, and access other devices (including network gear). Reading memory of remote hosts (ie RDMA) is also a thing which Nvidia gpus can do.

Is that not solvable using an IOMMU (assuming hardware that has one)?

No idea personally. :)

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

#240
post #205
post #107

Earlier quoted context omitted.

> 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. That's the opposite of my experience. I'd love to support open-source. But the AMD experience is just too flaky, too card-dependent. NVidia is rock-solid (maybe not for Wayland, but I never wanted Wayland in the first place).

What kind of flakiness? The only AMD GPU problem I have had involved a lightning strike killing a card while I was gaming. My nvidia problems are generally software and update related. The NVidia stuff usually works on popular distros, but as soon anything custom or a surprise update happens then there is a chance things break.

> What kind of flakiness?

Black screens, X server crashes, OpenGL programs either crashing or running slow. Just general unreliability. Different driver versions seemed more reliable than others, which meant I was always very reluctant to upgrade, which then gives you more problems as you end up pinning old versions which then makes it harder to troubleshoot online...

> My nvidia problems are generally software and update related. The NVidia stuff usually works on popular distros, but as soon anything custom or a surprise update happens then there is a chance things break.

I mean if you run mixed versions then yeah that will work for some upgrades and not others. A decent package manager should prevent that; some distros refuse to put effort into packaging the nvidia-drivers out of principle. But if you keep the drivers in sync (which is what the official package from NVidia themselves does, it's not their fault some distros choose to explode it into multiple packages) and properly rebuild just the kernel module every time you do a kernel upgrade (or just reinstall the whole driver if you prefer), then it's rock solid.

Post reply on HN