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)
The press release does say that they have plans to figure out a more upstream friendly approach in the long term, which is great - and what has been released will undoubtedly help development of the existing nouveau codebase.
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.
> This is not upstreamable in its current form (nvidia admit this in their press release)
True, I remember though that the semi-recent AMD Radeon drop was not immediately merge-able to mainline because they used a bespoke hardware abstraction layer. But (as alluded to by your point #1) it's a huge first step, and in AMD's case I think they eventually reworked it so that it could indeed be merged.
Nvidia have merely moved their giant closed source drivers into "firmware" - they now have a 34Mb firmware image for the GPU, that would be more correctly called the real drivers. They have essentially created an open source GPL forwarding layer so that the non-GPL firmware gets access to GPL-only kernel APIs, that's it.
Had to do a few doubletakes on this, but even with the recent hacks and progress on NVIDIA releasing Tegra source code, I didn't expect this for another few years.
Holy shit.
It's even licensed as MIT.
Even OpenBSD could conceivably port this with enough manpower. Adding enough just emulation for the userspace driver would be a lot easier than maintaining a complete linux emulator.
This is one of the biggest things to happen to hardware support for open source OSes in well over a decade.
>. Adding enough just emulation for the userspace driver would be a lot easier than maintaining a complete linux emulator.
OpenBSD it's the best BSD on support for free (Intel) and semi free drivers such as the ones from AMD, they already adapted all the src from Linux, KMS included.
Note that this is just the kernel modules, not the actual graphics driver.
IIRC these sources were already released under a permissive license along with their driver distribution. This just seems to be them putting those sources on GitHub and being more open to contributions.
The kernel driver was never distributed as source. The driver itself was a giant compiled object file that was linked into a kernel module with some shim code using DKMS. I know because I dug through it trying to fix the RTX 2060 in my G14 not going into D3.
> In this open-source release, support for GeForce and Workstation GPUs is alpha quality. GeForce and Workstation users can use this driver on Turing and NVIDIA Ampere architecture GPUs to run Linux desktops and use features such as multiple displays, G-SYNC, and NVIDIA RTX ray tracing in Vulkan and NVIDIA OptiX. Users can opt in using the kernel module parameter NVreg_EnableUnsupportedGpus as highlighted in the documentation. More robust and fully featured GeForce and Workstation support will follow in subsequent releases and the NVIDIA Open Kernel Modules will eventually supplant the closed-source driver. Customers with Turing and Ampere GPUs can choose which modules to install. Pre-Turing customers will continue to run the closed source modules.
Translating & simplifying the language here: sounds like GTX 10xx GPU users (Pascal architecture, e.g. 1070/1080) will stick with closed source for now, but RTX 20xx GPU users (Turing architecture, e.g. 2080) and RTX 30xx GPU users (Ampere architecture, e.g. 3080) will have the option to opt-in to the open source kernel module. Stable open source support for GTX 10xx GPU users may come later.
The reason for this is because NVIDIA's Turing and above GPUs use a new microcontroller called the GSP, which is RISC-V based. From my understanding, NVIDIA has offloaded their proprietary IP from the closed-source driver to the GSP firmware (and not the older microcontroller present on Pascal and lower). This is why `gsp.bin` exists in `linux-firmware` now, and the FOSS driver targets the GSP (because now the proprietary stuff isn't in the kernel driver but rather a RISC-V ELF binary that runs on the GPU), not the older controller.
What about GTX 16xx users? I have a GTX 1650 which is based on Turing but doesn't have the new NVENC encoder, I wonder if the new OSS driver will support this GPU, if it has that RISCV chip that everyone's talking about.
For those who didn't use Nvidia on linux in the old times:
The driver 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. So, Nvidia provided a small open source shim which interfaced between the kernel and the proprietary module.
You had to compile that shim yourself with the right arcane command line incantations and if you did anything wrong, missed the right packages or had an incompatible user space, including libs and compiler, you could end up without X11 and no way to easily run a browser or google about the problem you had. You had to do it EVERY FUCKING TIME YOU UPDATED THE KERNEL!
It was still possible to edit xorg.conf or, if you were older, xf86config by hand to fix it and use the VESA driver, but it was very inconvenient. It became more reliable over the time and even fully automated with DKMS, but I hated them for it.
I used and recommended ATI and INTEL for most of the people I could for a long time because of this.
I was from a time when It was possible to use 3D acceleration on linux with 3dfx with fully open source drivers (I think), giving you a cheap UNIX-like graphical workstation with OpenGL support. When Nvidia bought 3dfx and simply killed their drivers, my hate became specially strong.
EDIT: Remember you had to recompile the shim at every kernel update and replaced "module" with "driver".
> I used and recommended ATI and INTEL for most of the people I could for a long time because of this.
Same here but recently I somehow got a 3700X and there's no integrated GPU so I had to look for a GPU. I like my PC not just quiet but nearly silent, so a GPU with a fan was a big no-no. I couldn't find any single GPU able to drive 3840x1600 without a fan... Except for a NVidia one. Of course the proprietary Linux drivers are somehow buggy: the "sleep" doesn't work correctly, failing to reinitialize the correct video mode when waking up. It's always, always, always the same with NVidia GPUs on Linux. Thankfully I can switch to tty2, then back to graphical mode but I hate the inconvenience.
I'm thinking about selling my 3700X and getting a 12th gen Intel with an integrated GPU (I don't game and really couldn't care less about fast GPUs).
> 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.
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.
That's basically still what happens. Fedora automates this nicely with akmods, which automatically rebuilds these source only modules and installs them when you update the kernel. Has been working smoothly for a while, but it is fundamentally the same thing still.
I remember using that for a Geforce2 MX and the installer.
People has no idea on what FREEDOM do you have if you aren't bound to crappy licenses with Nvidia and CUDA for serious computing where you can be limited per core.
On Debian I do: module-assistant build-install nvidia
And it works every time, but you do need to run it every time. There is a way to automate it on new kernel installs.
> missed the right packages or had an incompatible user space, including libs and compiler, you could end up without X11 and no way to easily run a browser or google about the problem you had
I always kept the previous version of the kernel and module in case of this.
I've been recompiling my nvidia module each kernel release for over a decade and I've had no problems, you install the kernel, you install the nvidia module, and you reboot.
I did a double take because the title is almost clickbait for us desktop Linux users, and immediately wondered "what's the catch?". It's a significant catch, but also a significant step in the right direction.
I've never properly understood why the closed source AMD driver still exists. Is it substantially different from the open source one? Does it offer anything not included in the open source one?
With this announcement, I'm now interested in trying out some Nvidia graphics cards on the Pi again. Nouveau had some issues, and the official drivers had no source available, so I couldn't hack them to work.
With the source available... it could be possible! Of course, CUDA support may never happen there, at least not using open source code.
23 years ago in middle school I made my first ever linux user group post [1] trying to shift from an nvidia geforce to the onboard cyrix mediagx drivers because they had closed source drivers.
Haha that's awesome! I was 1 yo 23 years ago, but in the same vein, I had my middle school years of Linux. Although it was significantly simpler than what you were up to at the same age!
The datacenter focus here probably just means that $$$$ did the talking somewhere. AKA some large customer/former customer/potentially former customer said "open source or else" and they decided that having a couple people clean up, and push the special bits into the firmware/etc was a good way to solve the problem and keep $ALTERNATIVE at bay for the next generation or two.
I'd be interested to know too. The hackers purportedly demanded release of the Nvidia drivers as open source:
> The LAPSUS$ hacking group, which has taken credit for the breach, had an unusually populist demand: it stated that it wants Nvidia to open source its GPU drivers forever and remove its Ethereum cryptocurrency mining nerf from all Nvidia 30-series GPUs (such as newer models of the RTX 3080) rather than directly asking for cash. [1]
> The current codebase does not conform to the Linux kernel design conventions and is not a candidate for Linux upstream. [...]
> In the meantime, published source code serves as a reference to help improve the Nouveau driver. Nouveau can leverage the same firmware used by the NVIDIA driver, exposing many GPU functionalities, such as clock management and thermal management, bringing new features to the in-tree Nouveau driver.
Nouveau is still needed because Nvidia's drivers do not conform to Linux kernel standards, so they can't be upstreamed. Nouveau is conforming, so it still has a reason to exist. Fortunately Nouveau can more easily improve by using Nvidia's now-open source as a reference.
Nouveau is still needed if you want open-source userland; the new nvidia open source thingy is only kernel-side and presumably works only with their own userspace drivers.
> the user space stuff (OpenGL/Vulkan) is still closed source. (A LOT of heavy lifting is done here.)
Much like AMD - surely they benefit a lot from having a relatively stable non-kernel ABI they can target, though. The problem right now is that everything changes every time the kernel is updated, but if you turn it into a "here's how you dispatch PTX to the card" layer and a "here's how you turn OGL/Vulkan into PTX" blob then the dispatch layer probably isn't changing as much.
(graphics doesn't really use PTX but you get what I mean... dispatching compiled assembly and graphics API calls to the card.)
It doesn't help further the copyleft cause as much as if NVIDIA had open-sourced everything, of course, but from an end-user perspective of "I don't want my kernel updates to be tied to my driver release-cycle" it should solve almost all of the problem?
Nouveau has very close to 100% openGL and ES support. It has a deficit of out of specs extensions support though.
Also no opensource nvidia vulkan implementation??
If I understand this correctly nvidia is moving its proprietary code from the drivers to the card itself. Looks like we are looking at a future where graphic cards will get firmware updates instead of driver updates.
I am wondering with how large the newest graphics cards and ho the power requirements are so much larger than the other components. I see a future where we have PC cases and laptops with a pci slot exposed externally to attach external graphics cards which has it's own power supply and cooling only. It is attached to the PC when you need the GPU power for gaming or work then just remove it for a silent PC. As we start hitting the physical limits for moores law I think such a future is big possibility.
Was this an ongoing thing? Did it have to be pitched hard? What finally made the difference? I'm assuming here it's not because of LAPSUS as some speculate. This seems like it must have been in the making for quite a while.
I didn't work on this but I have watched it with interest for a very long time. It has been a strategic initiative in order to improve the GPU compute ecosystem. No one loves having a tainted kernel and everyone who uses a GPU with Linux (which is almost all data center GPUs) would prefer to have the kernel modules open source. It took a lot of work and planning to figure out how to do this over many teams for a very long time, and then an enormous amount of testing to prove the new drivers were fast enough to be deployed.
> Open kernel modules support all Ampere and Turing GPUs. Datacenter GPUs are supported for production, and support for GeForce and Workstation GPUs is alpha quality.
Sounds like this is not going to be what I game on for at least a little bit?
That's not really surprising when they are importing to a new repo and they aren't sure there isnt anything confidential (or bad optics) in previous commits or message
So is it correct that they are only open-sourcing the kernel-mode portion of the driver and that the real meat of the driver like the shader compiler will remain in a closed-source binary?
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.
Since the open sourced drivers are explicitly stated in TA to also help the Nouveau driver improve, the latter does not matter that much. That's what Mesa is here for.
I'm confused! Why would Nvidia want to keep any of this closed source. Surely they make money when people buy graphics cards, and having open source out-of-the-box graphics support in Linux would mean they would sell more graphics cards?
They only really care about Linux usage in embedded computers (Jetson) and in datacenters, and Free drivers would allow you to modify them to permit using consumer GPUs in virtual machines. Currently, you need to spend significantly more money for an enterprise GPU that has the same specs as a consumer GPU just so the driver will allow you to use GPU passthrough. They did recently allow consumers to pass a GPU to a single Windows VM guest so you could run a Windows-only game, but you can't split access to the single GPU among multiple VMs.
Drivers are a large part of the development costs of a GPU, just like how an operating system is a large part of the development cost of a general computer.
If nVidia open sourced all their drivers tomorrow the risk of some cheap Chinese shop making clones of their hardware and re-targeting the nVidia drivers to get lots of the features would be very high. It'd significantly reduce the value of what they'd built (to them).
Really, I don't get why so many Linux users ask questions like this. Most software is proprietary because it costs money to develop. This site we're talking on isn't open source. Windows isn't. macOS / iOS isn't. Games generally aren't. Google isn't. Azure/Bing aren't. Open source is the exception, not the norm.
It seems the modules bridge the kernel with the driver [1], so it is this part that is GPL/MIT, the driver itself is still a binary blob.
AMD probably does the same? Correct me if I'm wrong.
I first used OpenGL on linux in 1995. Software-based commercial X server that was unusably slow. By 98 or so I had Mesa, and was running software-based open source OpenGL (still pretty slow, but almost usable). By 2001, I think, I had a FireGL card that was supported in linux doing hardware OpenGL, I think it was a partly open source kernel driver- first time I had competitive performance to lower-end SGIs in the lab). FireGL was then acquired by ATI which sold their cards as high-end and continued the driver. After that I reverted to software for driver reasons, then to the nvidia driver, which I've used on linux for over a decade now. I will give ATI and nvidia credit for having at least some fairly good level of support for linux over the past two decades.
This is what happens when you don't just give up and "be pragmatic". Kudos to NVidia for coming to the table, and I look forward to seeing more of this sort of thing.
No, there's no reason for NVIDIA to react to that. Anyone working in the industry even glancing at a leak from the competitor would become a toxic legal liability. It's been a problem for reactos with windows leaks, and it would be orders of magnitude worse for NVIDIA/AMD.
This may be a boon for unlocking hardware features on GeForce. Stuff like below shows that some things are just disabled in hardware, but lots of reverse engineering would be needed to bypass it.
And just like that my next gpu will probably be NVIDIA. AMD's recent prices have made nvidia look like a better option and the only thing holding me back was amd's amazing open source drivers and the options that came with. If nvidia's drivers become comparable or are well on their way then they would be the obvious choice in today's market.
This is such good news... I hope we see 'real world improvements soon' !
The amount of time, I was 'sucked' with a black-screen after a reboot and the amount of time I wasted with Nvidia drivers ! I swear I would never buy NVIDIA again !
This. A clutch of really nice laptops fail hard when you include the .ko GPU blobs, and most developers in BSD land shrug and say "use VESA 2D" which is fine, for all but high-DPI use. (ok, its fine everywhere, but sub-par. you use more grunt doing less work to try and deal with dumb video device)
so ok, not exactly "this == CUDA" but this == decent kernel module drivers for the GPU.
Just out of curiosity, how easy would it to have been to decompile and reverse-engineer the original closed-source modules and then write an open sourced version of them? Would that have been legal?
Most importantly, will they open source Optimus? Even though the drivers work, getting everything to render on the GPU, and output to the laptop LCD, has always been an inconsistent pain.
That makes ThinkPads with Linux look much different than before compared to MacBooks with macOS. (And save a lot of update/re-configure/re-install cycles...)
The Steam Deck uses an AMD GPU, so it was probably the other way around. I'm betting this was partly done so nVidia GPUs can be used in similar devices going forward.
I was worried they had actually decided not to do this after seeing all of the other recent developments and then a pause. Glad to see it was just part of the path to it.
I believe everyone is the comments are like, "Omg! They finally took us seriously telling they are horrible at writing drivers for Linux". Good job Nvida
I wonder if it is the result of the LAPSUS$ hack. This was their statement from early March:
"After evaluating our position and Nvidia's, we decided to add one more requirement."
"We request that Nvidia commits to completely Open Source (an distribute under a FOSS License) ther GPU drivers for Windows, macOS and Linux, from now on and forever."
"If this request is not met, on Friday we will release the complete Silicon, Graphics and Computer Chipset Files for all recent Nvidia GPUs."
I don't think so. Phoronix.com just over a year ago reported that a big GPU maker was going to open source their drivers. I can't find the link but I believe this thing has been in the making for a long while
This doesn't actually solve the major standing issue with Nvidia's drivers as far as I'm aware, because the biggest thorn has been the secretful FALCON units, and the code signing of firmware blobs that's kept projects like nouveau from being able to gain traction.
Remember, it isn't enough that the kernel module is FOSS. The firmware is where the crux is.
Some comments were deferred for faster rendering.
mjg59|3 years ago
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)
The press release does say that they have plans to figure out a more upstream friendly approach in the long term, which is great - and what has been released will undoubtedly help development of the existing nouveau codebase.
mort96|3 years ago
smcl|3 years ago
True, I remember though that the semi-recent AMD Radeon drop was not immediately merge-able to mainline because they used a bespoke hardware abstraction layer. But (as alluded to by your point #1) it's a huge first step, and in AMD's case I think they eventually reworked it so that it could indeed be merged.
boberoni|3 years ago
What does "upstreamable" mean in this context? Is this good or bad?
As a follow-up, what would need to be different so that it is upstreamable and would that be good or bad?
olliej|3 years ago
Nvidia have merely moved their giant closed source drivers into "firmware" - they now have a 34Mb firmware image for the GPU, that would be more correctly called the real drivers. They have essentially created an open source GPL forwarding layer so that the non-GPL firmware gets access to GPL-only kernel APIs, that's it.
unknown|3 years ago
[deleted]
themusicgod1|3 years ago
messe|3 years ago
Holy shit.
It's even licensed as MIT.
Even OpenBSD could conceivably port this with enough manpower. Adding enough just emulation for the userspace driver would be a lot easier than maintaining a complete linux emulator.
This is one of the biggest things to happen to hardware support for open source OSes in well over a decade.
jjoonathan|3 years ago
I like back-foot, underdog NVIDIA. Ascendent AMD hasn't drawn my ire yet, let's hope power corrupts slowly.
orra|3 years ago
Wouldn't be the first time. The old 2D "nv" driver was part of X11, and maintained by Nvidia employees.
The catch, besides it being 2D only, was the "source code" was actually somewhat obfuscated.
onphonenow|3 years ago
anthk|3 years ago
>. Adding enough just emulation for the userspace driver would be a lot easier than maintaining a complete linux emulator.
OpenBSD it's the best BSD on support for free (Intel) and semi free drivers such as the ones from AMD, they already adapted all the src from Linux, KMS included.
unknown|3 years ago
[deleted]
samstave|3 years ago
[deleted]
hansihe|3 years ago
IIRC these sources were already released under a permissive license along with their driver distribution. This just seems to be them putting those sources on GitHub and being more open to contributions.
jakogut|3 years ago
amluto|3 years ago
On quick inspection, this is a complete, MIT-licensed kernel driver.
odensc|3 years ago
tomxor|3 years ago
pluc|3 years ago
But this is different, it's voluntary.
pixelmonkey|3 years ago
Translating & simplifying the language here: sounds like GTX 10xx GPU users (Pascal architecture, e.g. 1070/1080) will stick with closed source for now, but RTX 20xx GPU users (Turing architecture, e.g. 2080) and RTX 30xx GPU users (Ampere architecture, e.g. 3080) will have the option to opt-in to the open source kernel module. Stable open source support for GTX 10xx GPU users may come later.
kaladin-jasnah|3 years ago
jabl|3 years ago
Nope, Turing or later gen GPU is a hard requirement.
lolcat_cowsay|3 years ago
marcodiego|3 years ago
The driver 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. So, Nvidia provided a small open source shim which interfaced between the kernel and the proprietary module.
You had to compile that shim yourself with the right arcane command line incantations and if you did anything wrong, missed the right packages or had an incompatible user space, including libs and compiler, you could end up without X11 and no way to easily run a browser or google about the problem you had. You had to do it EVERY FUCKING TIME YOU UPDATED THE KERNEL!
It was still possible to edit xorg.conf or, if you were older, xf86config by hand to fix it and use the VESA driver, but it was very inconvenient. It became more reliable over the time and even fully automated with DKMS, but I hated them for it.
I used and recommended ATI and INTEL for most of the people I could for a long time because of this.
I was from a time when It was possible to use 3D acceleration on linux with 3dfx with fully open source drivers (I think), giving you a cheap UNIX-like graphical workstation with OpenGL support. When Nvidia bought 3dfx and simply killed their drivers, my hate became specially strong.
EDIT: Remember you had to recompile the shim at every kernel update and replaced "module" with "driver".
TacticalCoder|3 years ago
Same here but recently I somehow got a 3700X and there's no integrated GPU so I had to look for a GPU. I like my PC not just quiet but nearly silent, so a GPU with a fan was a big no-no. I couldn't find any single GPU able to drive 3840x1600 without a fan... Except for a NVidia one. Of course the proprietary Linux drivers are somehow buggy: the "sleep" doesn't work correctly, failing to reinitialize the correct video mode when waking up. It's always, always, always the same with NVidia GPUs on Linux. Thankfully I can switch to tty2, then back to graphical mode but I hate the inconvenience.
I'm thinking about selling my 3700X and getting a 12th gen Intel with an integrated GPU (I don't game and really couldn't care less about fast GPUs).
throw0101a|3 years ago
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?
alksjdalkj|3 years ago
linuxhansl|3 years ago
That's basically still what happens. Fedora automates this nicely with akmods, which automatically rebuilds these source only modules and installs them when you update the kernel. Has been working smoothly for a while, but it is fundamentally the same thing still.
Vladimof|3 years ago
I haven't bought NVIDIA since then
anthk|3 years ago
People has no idea on what FREEDOM do you have if you aren't bound to crappy licenses with Nvidia and CUDA for serious computing where you can be limited per core.
ars|3 years ago
And it works every time, but you do need to run it every time. There is a way to automate it on new kernel installs.
> missed the right packages or had an incompatible user space, including libs and compiler, you could end up without X11 and no way to easily run a browser or google about the problem you had
I always kept the previous version of the kernel and module in case of this.
I've been recompiling my nvidia module each kernel release for over a decade and I've had no problems, you install the kernel, you install the nvidia module, and you reboot.
eru|3 years ago
You don't need X11 to run a browser. But you are right that it's pretty inconvenient without.
eointierney|3 years ago
This is great news
dmead|3 years ago
unknown|3 years ago
[deleted]
Teknoman117|3 years ago
[deleted]
ASalazarMX|3 years ago
bombcar|3 years ago
jacooper|3 years ago
The closed source driver still exists but there will hopefully be a completely open source stack (Nouveau++?) For nvidia.
This blog has more details about red hats plans for this driver.
https://blogs.gnome.org/uraeus/2022/05/11/why-is-the-open-so...
sobkas|3 years ago
I can only hope they change name to aidivn, like any sane driver should.
feanaro|3 years ago
geerlingguy|3 years ago
With the source available... it could be possible! Of course, CUDA support may never happen there, at least not using open source code.
jacooper|3 years ago
remexre|3 years ago
adolph|3 years ago
Thank you for the work you do, I'm going through your ssd on rpi4 today!
viksit|3 years ago
It’s been a long time coming lol.
[1] https://www.spinics.net/lists/xf-xpert/msg04601.html
blihp|3 years ago
spyremeown|3 years ago
Haha that's awesome! I was 1 yo 23 years ago, but in the same vein, I had my middle school years of Linux. Although it was significantly simpler than what you were up to at the same age!
sylware|3 years ago
I wonder how much LAPSUS$ hack has to do with it.
I wonder if nvidia hardware programing interface is a mess like AMD one, just curious.
dralley|3 years ago
Probably zero.
1) There have been rumors about this for months
2) The hacks only happened very recently, this certainly would have taken longer to do than that.
aspaceman|3 years ago
moffkalast|3 years ago
the_duke|3 years ago
StillBored|3 years ago
ssl232|3 years ago
> The LAPSUS$ hacking group, which has taken credit for the breach, had an unusually populist demand: it stated that it wants Nvidia to open source its GPU drivers forever and remove its Ethereum cryptocurrency mining nerf from all Nvidia 30-series GPUs (such as newer models of the RTX 3080) rather than directly asking for cash. [1]
[1] https://www.theverge.com/2022/3/4/22962217/nvidia-hack-lapsu...
alaricus|3 years ago
evolve2k|3 years ago
These folks look like they’ve barely touched much open source code before now.
A planned run up would surely have these folks doing more GitHub based commits even if on very private repos.
marcodiego|3 years ago
Serious, does it means we won't need Nouveau anymore? How many and which binary blobs it still needs? Are they encrypted or require signing?
verst|3 years ago
> The current codebase does not conform to the Linux kernel design conventions and is not a candidate for Linux upstream. [...]
> In the meantime, published source code serves as a reference to help improve the Nouveau driver. Nouveau can leverage the same firmware used by the NVIDIA driver, exposing many GPU functionalities, such as clock management and thermal management, bringing new features to the in-tree Nouveau driver.
gary_0|3 years ago
zokier|3 years ago
dzogchen|3 years ago
jacooper|3 years ago
But the goal is to create a complete open source stack like MESA for AMD.
Also its only for Turing and newer (GTX 16XX+) https://blogs.gnome.org/uraeus/2022/05/11/why-is-the-open-so...
pabs3|3 years ago
intsunny|3 years ago
https://www.phoronix.com/scan.php?page=article&item=nvidia-o...
Main takeaways:
- support for gaming workstation GPUs is alpha
- the user space stuff (OpenGL/Vulkan) is still closed source. (A LOT of heavy lifting is done here.)
dang|3 years ago
Edit: ok, changed back
paulmd|3 years ago
Much like AMD - surely they benefit a lot from having a relatively stable non-kernel ABI they can target, though. The problem right now is that everything changes every time the kernel is updated, but if you turn it into a "here's how you dispatch PTX to the card" layer and a "here's how you turn OGL/Vulkan into PTX" blob then the dispatch layer probably isn't changing as much.
(graphics doesn't really use PTX but you get what I mean... dispatching compiled assembly and graphics API calls to the card.)
It doesn't help further the copyleft cause as much as if NVIDIA had open-sourced everything, of course, but from an end-user perspective of "I don't want my kernel updates to be tied to my driver release-cycle" it should solve almost all of the problem?
madushan1000|3 years ago
SemanticStrengh|3 years ago
https://mesamatrix.net/
xbmcuser|3 years ago
black_puppydog|3 years ago
Was this an ongoing thing? Did it have to be pitched hard? What finally made the difference? I'm assuming here it's not because of LAPSUS as some speculate. This seems like it must have been in the making for quite a while.
bcatanzaro|3 years ago
alaricus|3 years ago
He says that Nvidia's interest intensified in the last 3 months. Probably Steam Deck challenging their monopoly is making them uneasy.
johnny22|3 years ago
[deleted]
BeefySwain|3 years ago
Sounds like this is not going to be what I game on for at least a little bit?
johnny22|3 years ago
wallaBBB|3 years ago
Catastrophe is upon us!
alaricus|3 years ago
8organicbits|3 years ago
> Showing 2,519 changed files with 1,060,036 additions and 0 deletions.
bawolff|3 years ago
zokier|3 years ago
> With each new driver release, NVIDIA publishes a snapshot of the source code on GitHub
That definitely sounds like squashed commits will be the norm for now
GlitchMr|3 years ago
> There will likely only be one git commit per driver release.
voldacar|3 years ago
kadoban|3 years ago
I've been on linux for at least a couple of decades now, and this has been a thorn in my side from the get-go. I can't overstate how huge this is!
Great work Nvidia, seriously. It does look like it's not perfect, but damn it's a great step.
etaioinshrdlu|3 years ago
kaladin-jasnah|3 years ago
parasense|3 years ago
samus|3 years ago
Luker88|3 years ago
https://twitter.com/marcan42/status/1524615058688724992
34MB firmware
Good, but I'll try to stick with AMD. If only AMD's opencl support was better...
paulmd|3 years ago
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...
AMD still has closed-source binary blobs in their cards too, as does everyone else. Their userland is also closed-source too, just like NVIDIA's.
teekert|3 years ago
est31|3 years ago
ece|3 years ago
Pr0ject217|3 years ago
Humphrey|3 years ago
lights0123|3 years ago
native_samples|3 years ago
If nVidia open sourced all their drivers tomorrow the risk of some cheap Chinese shop making clones of their hardware and re-targeting the nVidia drivers to get lots of the features would be very high. It'd significantly reduce the value of what they'd built (to them).
Really, I don't get why so many Linux users ask questions like this. Most software is proprietary because it costs money to develop. This site we're talking on isn't open source. Windows isn't. macOS / iOS isn't. Games generally aren't. Google isn't. Azure/Bing aren't. Open source is the exception, not the norm.
alaricus|3 years ago
snshn|3 years ago
zekrioca|3 years ago
[1] https://github.com/NVIDIA/open-gpu-kernel-modules/tree/main/...
puffoflogic|3 years ago
jwithington|3 years ago
comandillos|3 years ago
adolph|3 years ago
"Currently, the kernel modules can be built for x86_64 or aarch64."
wmf|3 years ago
XorNot|3 years ago
unknown|3 years ago
[deleted]
dekhn|3 years ago
yellowapple|3 years ago
gchamonlive|3 years ago
_uiyh|3 years ago
endgame|3 years ago
unknown|3 years ago
[deleted]
hex69|3 years ago
blondie9x|3 years ago
WE REQUEST THAT NVIDIA COMMITS TO COMPLETELY OPEN-SOURCE (AND DISTRIBUTE UNDER A FOSS LICENSE) THEIR GPU DRIVERS”
https://www.theverge.com/2022/3/1/22957212/nvidia-confirms-h...
viraptor|3 years ago
8organicbits|3 years ago
https://www.ibtimes.com/nvidia-geforce-graphics-card-virtual...
kaladin-jasnah|3 years ago
unknown|3 years ago
[deleted]
samtheDamned|3 years ago
JCWasmx86|3 years ago
unknown|3 years ago
[deleted]
rawoke083600|3 years ago
The amount of time, I was 'sucked' with a black-screen after a reboot and the amount of time I wasted with Nvidia drivers ! I swear I would never buy NVIDIA again !
zepearl|3 years ago
NexRebular|3 years ago
ggm|3 years ago
so ok, not exactly "this == CUDA" but this == decent kernel module drivers for the GPU.
iepathos|3 years ago
unknown|3 years ago
[deleted]
smw|3 years ago
anonymousDan|3 years ago
ncmncm|3 years ago
But anyway, the user-space stuff is still the same. This only affects the kernel modules.
cosmiccatnap|3 years ago
Fucking finally.
pmoriarty|3 years ago
wmf|3 years ago
Bancakes|3 years ago
Most importantly, will they open source Optimus? Even though the drivers work, getting everything to render on the GPU, and output to the laptop LCD, has always been an inconsistent pain.
haupt|3 years ago
blablabla123|3 years ago
unknown|3 years ago
[deleted]
jpe90|3 years ago
jabl|3 years ago
mc4ndr3|3 years ago
dzogchen|3 years ago
test6554|3 years ago
jwithington|3 years ago
e12e|3 years ago
umanwizard|3 years ago
pikseladam|3 years ago
DantesKite|3 years ago
jonny_eh|3 years ago
ghishadow|3 years ago
gjvc|3 years ago
pawelduda|3 years ago
zamadatix|3 years ago
skittleson|3 years ago
kiechu|3 years ago
figassis|3 years ago
cV6WB|3 years ago
pyuser583|3 years ago
floor_|3 years ago
Lapsa|3 years ago
InitEnabler|3 years ago
weinzierl|3 years ago
"After evaluating our position and Nvidia's, we decided to add one more requirement."
"We request that Nvidia commits to completely Open Source (an distribute under a FOSS License) ther GPU drivers for Windows, macOS and Linux, from now on and forever."
"If this request is not met, on Friday we will release the complete Silicon, Graphics and Computer Chipset Files for all recent Nvidia GPUs."
HidyBush|3 years ago
[edit] found it: https://www.phoronix.com/scan.php?page=news_item&px=Big-New-...
salawat|3 years ago
Remember, it isn't enough that the kernel module is FOSS. The firmware is where the crux is.
etaioinshrdlu|3 years ago
bogwog|3 years ago
Considering this is coming well after the supposed deadline, I don’t think it’s related.
Metacelsus|3 years ago
Since the deadline passed I guess Nvidia negotiated, or they were bluffing.
messe|3 years ago
unknown|3 years ago
[deleted]
xbar|3 years ago
unknown|3 years ago
[deleted]
SemanticStrengh|3 years ago
alaricus|3 years ago
[deleted]
exikyut|3 years ago
[deleted]
kodah|3 years ago
Shout out to nvidia for this.
marius_k|3 years ago
tonnydourado|3 years ago
throwaway8486|3 years ago
unknown|3 years ago
[deleted]
frogger8|3 years ago
https://news.ycombinator.com/item?id=30471005