The bits that implement the userland graphics libraries are closed source, unlike Mesa. So this is still useless, but don't get me wrong... I'll take it, but I'm still going to bitch about it. My hope is now folks will be able to adapt these Nvidia cards into the Mesa ecosystem, like ~10 years from now or whatever.
Nvidia releases open-source GPU kernel modules
291–300 of 415 posts
Re: Nvidia releases open-source GPU kernel modules
#292As predicted 3 months ago ;)
Re: Nvidia releases open-source GPU kernel modules
#293Earlier quoted context omitted.
If I remember correctly, the open source ATI drivers were always a bit buggy and it wasn't that easy getting them installed either. The tradeoff was always Nvidia: proprietary but works well, ATI: open but buggy.
> the open source ATI drivers were always a bit buggy and it wasn't that easy getting them installed either. No. Once mainlined, you had to do absolutely nothing to get the hardware working.
I'm pretty sure I needed to mess with xorg.conf and other settings to get things like screen resolution and Compiz working correctly. I don't know what part of the stack was responsible for those issues, but I thought it was related to the graphics driver.
I could be misremembering though, this was 15+ years ago now.
Re: Nvidia releases open-source GPU kernel modules
#2941) This is unambiguously Good News 2) This is not upstreamable in its current form (nvidia admit this in their press release) 3) In an ideal world, nouveau (the open source driver for nvidia hardware) would be able to target this kernel code. Right now though there's no commitment for any sort of stable userland ABI, and that makes that difficult (moving to a new driver version may break interfaces that nouveau uses)…
Sadly, it's also not the actual GPU driver, just the kernel part; you still need their massive closed blob in userspace. Almost had me excited there for a moment.
That's a bit of a tired and somewhat misleading argument.
Take a look into the kernel-firmware repo, and you will see a tremendous amount of binary firmware blobs. For example the Intel micro-code blobs are protected by ~7 layers deep of encryption, wifi drivers may have government regulatory issues with sharing firmwares in anything but binary form. So let's please drop the evil binary blob nonesense...
The kernel does in fact accept small or large binary blobs, and some of them even come with source code...So I guess the key takeaway is to look at what separate the Nvidia driver/firmware from all those other binary firmware loading drivers.
Hint, it has more to do with hiding the program interface, and using abstractions within abstractions.
Re: Nvidia releases open-source GPU kernel modules
#295Re: Nvidia releases open-source GPU kernel modules
#296Earlier quoted context omitted.
It means Nouveau will finally can get good I think.
Nope, nouveau is still hosed because they've been blocked ny Nvidia's secrutful FALCON's which have the reclocking and power management API's locked away behind proprietary firmware blobs.
nvidia switched away from FALCON to RISC-V.
Re: Nvidia releases open-source GPU kernel modules
#297Earlier quoted context omitted.
>Note that the kernel modules built here must be used with gsp.bin firmware and user-space NVIDIA GPU driver components from a corresponding 515.43.04 driver release. This can be achieved by installing the NVIDIA GPU driver from the .run file using the --no-kernel-modules option.
Closed source firmware is acceptable for Linux. See: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin... It would not be much of a stretch at all for nvidia to include their firmware there. The userspace stack is an issue. For upstream Linux, there’s a fairly hard rule that graphics driver interfaces must be usable with open source userspace. But I don’t think the nvidia graphics user parts are particular…
It already is for the 510 driver.
Re: Nvidia releases open-source GPU kernel modules
#298Yay!!!
Re: Nvidia releases open-source GPU kernel modules
#299Earlier quoted context omitted.
> The module was a proprietary binary. Since a kernel module requires interfacing with the kernel API, it could be considered a derivative work and a breach of the GPL license. I never quite understood this logic: the same (?) binary blob is used for the FreeBSD and Solaris drivers. * https://www.nvidia.com/en-us/drivers/unix/ So how can it be a 'derivative' of the GPL Linux if it it also used on non-GPL systems?
That's an interesting cognitive dissonance that I've always been fascinated by. I've heard people criticize developers who release proprietary drivers for the linux kernel, but never those who release something dual licensed as GPL2/MIT, or those who distribute a dual licensed GPL2/MIT module as if it were solely under the MIT license; surely that would violate the Linux kernel's GPL (in being a derivative work) as m…
MIT is Ok because MIT is compatible with GPL. GPL has language saying you can't add restrictions, but the combination GPL+MIT is essentially GPL so it's ok.
Dual GPL/MIT essentially means that you as a user can choose whether you to use the code as GPL or as MIT, but if you contribute to the code you must provide the full GPL+MIT rights.
As to why release a driver as GPL/MIT instead of just the GPL, I think the idea is that the BSD's (or other OS'es) can take the code and use it under the terms of the MIT license and port it to their kernels. IIRC there are many drivers in Linux that are dual licensed in this way for that reason.
Re: Nvidia releases open-source GPU kernel modules
#300Finally some good news for free software \o/