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.
It is far more important to have open sources for all programs that are executed in privileged mode than to have the source for the programs that are executed in user mode.
The kernel can control what a user-mode program does and limit its access to any hardware resources or CPU time, but it cannot do anything against kernel modules that are executed in privileged mode.
So having the source for all the kernel modules is the main priority. With this new open-source kernel module from NVIDIA, the only closed-source kernel module used by a large number of Linux users is no longer so.
Now the main problems remain the BIOS/UEFI of the computers, which is free to override what the operating system does, due to the exceedingly stupid System Management Mode invented by Intel, and the firmware for the auxiliary CPUs that may be used for unauthorized remote management in most Intel- and AMD-based computers.
You're right that this isn't about nVidia suddenly deciding to open source anything, but it's still good for compatibility reasons.
What is this effort?
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.
GP is likely referring to the userspace component of nvidia's driver, not the actual blob that gets loaded onto the gpu. If it is indeed true that you need to run proprietary userland code, then this open-source release is nothing but a way to circumvent the GPL issues that lead to nvidia's driver partially breaking in Linux 5.??.
While not ideal, I like many don't have a hard stance against loading proprietary hardware firmware blobs. I, however, absolutely take issue with running opaque user-space programs.
Is it licensed, or simply too too complicated to pick apart?
Graphics is a complicated field, but the techniques could still be patented - surely their market status isn’t dependent on trade secrets?
[1] https://www.tomshardware.com/news/nvidia-gpu-system-processo...
That will allow avoiding Nvidia blob except for the firmware.
Hopefully the GPU driver is next in their open-source roadmap.
In normal times that might be a fair way to get people to upgrade but in the last few years (when crypto bros and scalpers have gotten all the cards) it's been outright cruel.
But that aside, Turing is their first generation that a GPU System Processor (GSP) that runs the heavy binary blob that comes with the open source driver.
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.
This open-source kernel code is currently split into OS-agnostic and kernel interface layer components. This stems from NVIDIA's proprietary driver on Linux largely being shared code across Windows / Linux / FreeBSD / Solaris. For it to be upstreamed in the Linux kernel it would likely need to be more re-factored to cater to Linux, just as AMD's DAL/DC originally had tough time upstreaming due to its numerous abstractions.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?
"Upstream" is the kernel source tree maintained by Linus (and friends). As Linux is open source, anyone can fork it for any reason, and a lot of people do. However, Linus still maintains the common base that people use to build on top of. "Upstreaming" is the process of getting your code included in these official releases. It's significant because there are no stable interfaces inside the kernel. That is, in any release the Linux developers can change any internal system of the kernel in any way they please, with the only caveat that to get that change included they have to fix up any breakage it causes, but only inside upstream. Or, if you are building your own kernels with your own patch sets, any release of the kernel can completely break your build.
Because of this, if you want your code to be actually used by real people, upstreaming it is considered extremely good, to the point of being almost a necessity. However, it can be a significant hurdle to overcome. Partly because there are fairly strict code quality/style requirements (as any kernel dev is supposed to be able to jump into your code to fix issues they caused by modifications elsewhere), but mostly because unlike inside the kernel itself, all interfaces between kernel and userspace are stable. That is, if you start supporting some operation from userspace, you need to be able to support it in perpetuity. Also, the kernel devs are extremely reluctant to add any kind of interface to the kernel where the only thing that uses it is some specific non-free binary blob on the userspace side.
Currently the main reason the code is not upstreamable as is is that it needs a very substantial userspace program to function, which currently only exists as nonfree, and nVidia doesn't think that the interface used to connect to it is well-enough decided they want to freeze it.
So the main hurdle for upstreaming is developing that interface until they are happy with it, and then develop some free version of the userspace portion of their graphics stack that can plug into that same interface.
are we assuming some sort of automatic testing will be added? unit testing? integration testing? sounds super hard to do for a driver. but... high quality code just being merged into master can still have bugs introduced in the future on accident, right? it's tests that usually makes it safe?
It's a negative that it's not upstreamable. I wouldn't go so far as to say it's bad, but it's less than good. That means you'll continue to maintain a separate kernel module that's rebuilt for each kernel.
It would need to be modified to match the kernel's coding standards and whatnot. Part of what makes linux such a strong thing is that you're just not allowed to do certain things in the kernel. They won't include ZFS in the kernel because it's got its own entire vfs -- linux filesystems are only permitted to use linux's vfs, and if you need vfs changes to make it work, you modify the 'one true' vfs. They didn't include the original AMD Radeon driver because it had its own hardware abstraction layer; you're supposed to do that in user space or not at all. (the Radeon driver was changed to remove the abstraction layer, and it was later merged into the kernel)
It's not immediately clear to me how much work it will take to get the driver into the kernel. Hopefully it won't be a lot of work, but it's possible that it would require basically rewriting it from scratch. It's at least written almost entirely in C, so that's a good start.
Regardless, this is tremendously good news.
Linux doesn't do pull requests. You actually send your patches as an email to a kernel maintainer (different people accept patches for different parts of the codebase) and then they'll review it. They'll pass it up to someone above them, and they'll pass it to someone above them, and eventually it makes its way to Linus.
That's why Linus is famous for angry and aggressive emails. He's not shouting down new developers who have made a simple mistake. He shouts and swears at the people employed below him who failed to properly do quality control and code review.
It just means you have to download drivers separately until Nvidia give the kernel guys a pull request for the drivers to be included in the kernel sources by default.
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.
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.
I like back-foot, underdog NVIDIA. Ascendent AMD hasn't drawn my ire yet, let's hope power corrupts slowly.
Both can/could be bypassed with some libvirtd xml magic, but still. Nvidia seem to slowly stop being assholes, AMD started already.
What? Why?
That "back-foot" "underdog" nVidia has the edge in the video market still... and 3x the market cap of AMD.
NVIDIA had to overclock and hustle the current generation of cards and it's looking even worse for the next generation. Software was a moat when AMD was heavily resource constrained, but now they can afford the headcount to give chase. Between the chip shortage and crypto, there was plenty of noise on top of fundamentals, but one doesn't make strategic plans based on noise.
This is all speculative, of course. I'm sure if asked they would say it was a total coincidence. Just like AMD and Intel switching places on their stance towards overclocking. Complete coincidence that it matches the optimal strategy for their market position -- "milk it" vs "give chase." Somehow it always seems to match, though, and speculation is fun :)
I feel like JUST as the "Linux X11 Discrete Graphics Scenario" started to become more stable and less (not none, but less) of an issue to setup and upgrade without getting black screens, the Linux-world is now turning to a "new windowing server" i.e Wayland, we starting all over again sigh
Maybe the answer to having a decent and carefree discrete graphics Linux stack is to fork (Don't you dare link to the XKCD comic about 'Standards') SteamOS.
They are at least motivated (as it's part of their core product) to make it work most of the time. And have a done boat load of good work for Linux ecosystem. Well done guys ! :)
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.
>. 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.
But, said translation layer would have limited scope; so is a lot more feasible than maintaining a general purpose translation layer indefinitely.
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.
On quick inspection, this is a complete, MIT-licensed kernel driver.
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 particularly secret, and someone could write such a thing.
My understanding as well was that the bulk of the kernel space driver was previously only available as a binary blob, with only a small shim layer open sourced that loaded the rest of the kernel module and translated all of the internal kernel calls. I heard a rumor this was actually core to their internal legal theory about why they could have a binary blob kernel driver.
Required firmware blobs and the user space libraries are ultimately different components in the stack.
But this is different, it's voluntary.
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.
Nope, Turing or later gen GPU is a hard requirement.
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".
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 actual name of the CPU should help you find one that would work in that regard, for example, see this link which explains the naming suffixes: https://www.androidauthority.com/amd-cpu-guide-1222438/
In particular:
X - Higher clocked desktop processor (what you got)
G - Has integrated AMD Radeon Vega Graphics (what you probably want)
GE - Has integrated AMD Radeon Vega Graphics but lower TDP (what you might want in niche use cases)
For the Zen 2 series that your 3700X belongs to, you might want to look at this table: https://en.wikipedia.org/wiki/List_of_AMD_Ryzen_processors#A...
From what i can tell, the closest option performance wise to Ryzen 7 3700X but with on board graphics would be Ryzen 7 4700G.
I have a server with a 3700x. I originally had a cheapo discrete AMD graphics card in it, but I ended up just yanking that and running the machine without any graphics card. Saves power.
in almost all situations, the "lower tier" CPUs can be replicated simply by taking the higher-tier CPU and setting a lower power limit. A 1800X with a 65W power limit is the same thing as a 1700, a 3400G with a 45W (?) power limit is the same thing as a 3400GE, etc. Since the "GE" chips and other niche SKUs (there is a 3700 non-X iirc, for example) are often OEM-only, and thus they only have a very limited availability, they will often command higher prices on ebay/etc than the "real" chip. In this case, there is no reason to seek out the "E" chip, with the possible exception of if it gets you the "pro" feature set and you happen to need one of the features (particularly for APUs since ECC is disabled on non-pro APUs). So if you see a 3400G for $200 and a 3400GE for $250 (made-up numbers) then don't buy the GE, buy the G and set the power limit yourself.
Lower-end chips do not have better binning - actually the opposite, higher-end chips have better binning and will run at lower voltages for a given frequency than the lower-end chips will. The "higher leakage clocks better" thing is not really a factor that matters on ambient cooling, that is for XOC doing LN2 or LHe runs, but it has entered the public consciousness that "low-TDP chips are binned for efficiency". Not in the consumer market they're not - the exceptions being things like Fury Nano that explicitly are binned better, and for which you pay a premium price for that efficiency. But most low-end consumer processors are just... low-end. They're priced according to performance, not binning.
You can see this in the SiliconLottery historically binning statistics: 1800X will categorically clock higher at any voltage than a 1700, a 3800X is categorically better at any voltage than a 3700X, etc - and that also means they will run a lower voltage at any target frequency. AMD bins straight-down in terms of chip quality: Epyc and TR get the best, then the high-end enthusiast chips, then the value enthusiast chips, then the efficiency parts at the bottom of the bins.
The "E" parts are efficient because they have a low power limit set - not because they're binned better. Lots of chips can run fine at lower voltages, they just don't do the peak frequencies as well as the binned chips. A 1800X will still get you a bit lower voltage - but since the voltage/power curve is quadratic, the difference in power is compressed at lower frequencies/voltages. Also, at a low-enough frequency you will bump into the minimum voltage required, so that tends to compress things as well. So at 3 GHz, the impact on binning between a 1800X and a 1700 would be a lot smaller than, say, at 4 GHz. The 1800X can usually do that fairly easily in a later sample, but 4 GHz is pretty much always pushing the limits of safe voltage for a 1700, for example, so the 1700 gets crappier silicon because it clocks lower.
https://siliconlottery.com/pages/statistics
https://www.reddit.com/r/Amd/comments/cll1r9/hardware_numb3r...
(the "one weird exception" is lower core-count chips. If you think of each core as a dice roll, this means that an 8-core chip has to roll perfectly 8 times, where a 6-core chip only has to roll perfectly 6 times. Since all-core OC is limited by the performance of the worst core, this means that for equal yields, there may be more lower-core-count chips with high all-core OCs. Many midrange parts do not actually have defective cores, they're locked out for market segmentation to avoid undercutting margins on the higher-end parts (which is why Phenoms and 7950s used to be unlockable, etc) and - while I'm not sure AMD has explicitly ever said it - it would also be sensible that when they are disabling cores on an 8-core to turn it into a 6-core they pick the best 6 cores, which would push silicon quality upwards too. A 1600X actually has silicon quality comparable to a 1800X according to SiliconLottery, for example, despite being a much higher-volume part. This "weird exception" also gets complicated with Zen2/Zen3 because AMD deliberately uses a low-quality die for the second CCD (3900X/3950X) since it will mostly be used under those lower-clocking all-core loads, and the impact of binning is compressed in those lower-clocking situations...)
This will end this situation, and give a nice bump to AMD's market share in e.g. Valve's steam client statistics.
These days, the performance of the embedded GPUs is already pretty usable, even allowing for running heavy videogames on lowish settings. They've been increasing the performance considerably (30-60%) on each generation for several generations.
It's why I ended up getting the (surprisingly) cheaper Intel equivalent. It has an iGPU and also PCIe 4.0.
> I don't game
Let me help. https://www.ebay.com/itm/194948432276 that's a full DP 1.2 port in there https://www.techpowerup.com/gpu-specs/sapphire-ultimate-r7-2... so it'll drive 3840 x 1600 up to 108 Hz even without custom mode shenanigans.
Also many GPUs support the fan turning off when idle.
I’ve been through a couple 12th gens. I like them, but unless you need the machine updated right now, 13th gen is 6 months out.
Almost no AIOs have the fluid-temperature sensors that would allow you to measure this directly, so everyone uses the die sensors. Which, since they're behind the IHS, will be much higher than the fluid itself. The die temperature is also a measurement of interest too - I'm merely explaining why the number you're seeing in the die sensor isn't really the big picture of how good the the radiator is doing at cooling. The die is hot, but the fluid is cool.
The AMD 295x2 is an extremely good example of this observation - this card had a single 120mm radiator, with one fan, and it could dissipate >500W of heat at ~60C die temperature. (not sure if this source says this directly but the non-OC power was ~430W average during gaming, and ~250W is not unreasonable for each 290X chip - actually they could go to 300W or higher if you really poured it on, but they also did generally show some significant power scaling with temperatures, so ~250W per chip/500W total is a reasonable estimate imo).
https://www.techpowerup.com/review/amd-r9-295-x2/28.html
You might say - but that's a dual-GPU card, with bare dies. And yes, that's my point, when the coldplate/IHS is no longer a bottleneck moving heat into the loop, a 120mm radiator is comfortably capable of dissipating 500W of power back out of the loop at extremely reasonable operating temperatures (60C die temperature). 60C is actually barely breaking a sweat, you could probably do 1000W through that 120mm if you didn't mind a die temperature in the 80-90C range. In CPU overclocking - your power limits/temps are almost entirely limited by how fast you can get that heat through the IHS. Reducing fluid temps (by increasing radiator size) is pushing on a string, it takes big gains in fluid temp to produce a small improvement in die temp.
Incidentally, direct-die cooling is the last untapped frontier of gains for ambient (non-chilled) overclocking. Der8auer and IceManCooler.com both make "support brackets" that replace part of the ILM (integrated loading mechanism - the socket and its tensioning mechanism and attachment to the motherboard) that holds the processor. This is necessary since the IHS is actually part of the ILM - the ILM presses down on the sides of the IHS, so removing it would change the pressure, and the ILM needs to keep a specific level of pressure on the chip to make a good contact with the pins but but without damaging anything. But you can delid the processor (there are services that do this for soldered chips, I don't recommend doing it at home) and use one of those brackets with a "normal" waterblock/AIO (or even air-cooler), since the bracket is holding the chip in the pin-bed at the proper tension.
Thermal density is going nowhere but up, Dennard scaling is over, so that is the only way to really improve thermals on <= 7nm-class nodes. Even AMD runs hot - they routinely run in the mid-80C range nowadays, even though they don't pull a lot of power - because of that thermal density, and every time they shrink it's going to get worse. The gains may be more worth it on Intel though - they show better scaling from power/voltage, TSMC nodes seem to pretty much top out at about 4 GHz and past there it gets exponentially worse for very little actual performance gain. 4.3, 4.4, sure, but they don't seem to do 5-5.3 GHz like Intel can on their Intel 7 given good temps and enough voltage.
But yes, to go back to your original point, I really like my 3090 Kingpin as well. It runs extremely cool, I can keep the die at literally 30C with the fans cranked all the way up, and it'll keep the VRAM at under 70C (!). And since it is a 2-slot card it doesn't turn into a compatibility mess with motherboard pcie slots getting blocked and needing airspace/etc. I am 100% behind AIOs on the larger gpus that we are seeing lately, this is a better solution than triple-slot or 3.5 slot coolers, which are (imo) completely ridiculous.
Don't suppose you're in Ireland/UK/EU? Looking at building a low/mid-range gaming rig for a sibling, and a 3700X would fit fine if you're looking to sell.
The card isn't silent, but it's quieter than the high end, low wattage PSU fan, which is needed to dissipate heat from everything else.
Anyway, eliminating the video card fan would probably make my desktop louder, which was counterintuitive to me at the time.
(The setup is extremely quiet, FWIW.)
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?
Note that the word "derivative" is used here as defined by the license, not in its plain English meaning.
But one gray area in particular is something like a driver that was
originally written for another operating system (ie clearly not a derived
work of Linux in origin). At exactly what point does it become a derived
work of the kernel (and thus fall under the GPL)?
THAT is a gray area, and _that_ is the area where I personally believe
that some modules may be considered to not be derived works simply because
they weren't designed for Linux and don't depend on any special Linux
behaviour.
Basically:
- anything that was written with Linux in mind (whether it then _also_
works on other operating systems or not) is clearly partially a derived
work.
- anything that has knowledge of and plays with fundamental internal
Linux behaviour is clearly a derived work. If you need to muck around
with core code, you're derived, no question about it.
Then you have things like (Open)ZFS and DTrace.
You rewrite that library under an MIT license, so now your code can link to that and run. Is your original code still a derivative work?
The license does not contain a definition for "derivative" nor of the similar term "derived" which it also uses.
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.
My Vega 56 has been perfectly stable and trouble-free for years.
No. Once mainlined, you had to do absolutely nothing to get the hardware working.
Up until somewhere around 2016-2017 the ATI/AMD drivers were really bad.
I had an "HD 7850" GPU on Linux around that time and it was barely usable. The performance was less than half of what you got on Windows, and the drivers would crash very often, sometimes several times a day if I was trying to play games like Team Fortress 2.
It was so bad that I decided to replace the HD 7850 with a new GTX 970 and decided to not buy anymore AMD GPUs for the indefinite future. The GTX 970 was stable and performed very well with the closed source drivers, and other than them being closed source I never had an issue with them. I always installed the closed drivers through the system package manager which handled all of the tricky stuff for me (Arch Linux maintains the nvidia driver as a system package and makes sure it runs on the current kernel before releasing it).
In modern times the situation has flipped though. I still haven't bought an AMD GPU since then but I am pretty sure my next one will be.
Around then, you still had to install the corresponding X11 portion of the drivers, though the nvidia eqiuvalent had the same limitation.
radeon/radeonhd, or fglrx (which was the propriertary AMD graphics) absolutely worked worse than nouveau or the proprietary nvidia drivers at that time. It was only a couple of years into amdgpu where the tables turned.
At this point it would be nice if they'd backport their Linux drivers to Windows, as I'm now on my third AMD GPU in 12-13 years (HD 5770, r9 290x, 6900XT) to have issues where the driver will randomly crash when playing hardware accelerated video on one monitor while playing a directx game on another monitor under Windows.
I could be misremembering though, this was 15+ years ago now.
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 haven't bought NVIDIA since then
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.
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.
You don't need X11 to run a browser. But you are right that it's pretty inconvenient without.
This is great news
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...
I can only hope they change name to aidivn, like any sane driver should.
The latter I wish was just a general purpose feature now that things like resizable bar are seeing general support in the consumer space.
* Proprietary shader compiler that can also be used for Vulkan
* Legacy OpenGL driver optimized for closed-source workstation apps
https://rebatir.fr/post/2022-01-25-OpenCL_on_Linux_state_of_...
If you don't care about that, you can run pretty much anything else and performance is great.
With the source available... it could be possible! Of course, CUDA support may never happen there, at least not using open source code.
Thank you for the work you do, I'm going through your ssd on rpi4 today!
It’s been a long time coming lol.
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!
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.
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.
Have a look at libdrm from the mesa project (the AMDGPU submodule), then it will give you pointers where to look into the kernel-DRM via the right IOCTLs.
Basically, the kernel code is initialization, quirks detection and restoration (firmware blobs are failing hard here), setting up of the various vram virtual address spaces (16 on latest GPUs) and the various circular buffers. The 3D/compute pipeline programing is done from userspace via those circular buffers.
If I am not too much mistaken, on lastest GPU "everything" should be in 1 PCIE 64bits bar (thx to bar size reprograming).
The challenge for AMD is to make all that dead simple and clean while keeping the extreme performance (GPU is all about performance). Heard rumors about near 0-driver hardware (namely "rdy" at power up).
Exactly the pointer I was looking for, thank you.
> 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...
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.
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?
> 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.
For now, the plan is to replicate the way AMD drivers
Work, with having shared firmware but separate user lands, one closed and the other libre(MESA for AMD, Nouveau++ for nvidia?)
More details here from Red hats Christian schaller
https://blogs.gnome.org/uraeus/2022/05/11/why-is-the-open-so...
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...
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.)
Edit: ok, changed back
I don't even dislike Phoronix, but what was wrong with the first-party source?
If you want to understand this process, you should understand that none of it involves actually reading the articles!
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?
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.
My own motivation is to believe that NVidia isn't as broken as everyone insists it is, I guess :) and more broadly speaking it honestly seems like a Good And Interesting Idea to make the situation more clear in any case, particularly given the coverage and significant collective awareness it's attracted.
Also, I found https://www.phoronix.com/scan.php?page=news_item&px=Big-New-... in another comment - 22 May to 12 May, that's some serious stamina lol
He says that Nvidia's interest intensified in the last 3 months. Probably Steam Deck challenging their monopoly is making them uneasy.
Sounds like this is not going to be what I game on for at least a little bit?
Catastrophe is upon us!
> Showing 2,519 changed files with 1,060,036 additions and 0 deletions.
> 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
> There will likely only be one git commit per driver release.
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.
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...
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.
Loading any out-of-tree module taints the kernel, for example the vbox modules are GPL: https://archlinux.org/packages/community/x86_64/virtualbox-h...
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.
The non-free features for the Nvidia cards and many other chips are achieved by the card itself running closed source binaries. It is actually probably a better way to protect IP anyway since no one can decompile the encrypted binary (well until recently...).
Open source and proprietary software exist as a duality. It's not an absolute expectation that everything will be open source but Nvidia is very late vs its competitors.
Google, Windows, macOS, etc. all have large open source parts. Games are kind of an exception because they are treated like a single work of art. Also, crucially no other software or hardware has a game as a dependency so interoperability isn't a concern.
Well I used to work at Google and the open source parts are a tiny, tiny fraction of their actual codebase. Windows isn't really open source at all, although in recent years a few utilities have been opened up - note, only after Windows stopped being so important to Microsoft.
And as for macOS. Well. You can download and read some code, sometimes. Good luck trying to actually build it or do anything useful with it at all. You'll find that it's (a) completely undocumented and (b) all depends on internal stuff you don't have access to. An exception is WebKit.
WTF are you talking about?
If any, science today it's made thanks to FLOSS software, propietary software it's the exception. And the trend it looking worse for propietary environments.
Money will come from support and integration, not for the software.
A complex, scientific related reproducible ad-hoc environment for Guix may cost a little more on a single PC than a a propietary OS license and setting up the rest for yourself, but you will be able to replicate that setup everywhere and forever and on a guaranteed basis that once your paper/experiment it's replicated, yo get the same environment no matter where and how. That's the difference.
Yes, we can all make long lists of open source projects. That's not my point. The point is that the average person, on an average day, is using lots of proprietary software (or proprietary forks of open source software).
I've been hearing about how the future of software is charging for support tickets and hand-waved 'integration' for 30 years. The biggest, richest and most powerful tech firms today all ignored that advice. There's only one company that did well out of that approach and they're now called IBM.
[1] https://github.com/NVIDIA/open-gpu-kernel-modules/tree/main/...
"Currently, the kernel modules can be built for x86_64 or aarch64."
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...
https://www.ibtimes.com/nvidia-geforce-graphics-card-virtual...
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 !
so ok, not exactly "this == CUDA" but this == decent kernel module drivers for the GPU.
But anyway, the user-space stuff is still the same. This only affects the kernel modules.
Fucking finally.
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.
"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."
[edit] found it: https://www.phoronix.com/scan.php?page=news_item&px=Big-New-...
Remember, it isn't enough that the kernel module is FOSS. The firmware is where the crux is.
Considering this is coming well after the supposed deadline, I don’t think it’s related.
Since the deadline passed I guess Nvidia negotiated, or they were bluffing.
Shout out to nvidia for this.