16xx, 20xx, 30xx, and some enterprise cards. Still great progress.

I saw this message scroll by during booting, somewhere in 2004? I searched for it online and those were my first lessons on foss and the GPL. How great to see this happening. Is it the hack (I don&#x27;t think so)? Is it the succes of Steam (Deck)? Is is Proton? Deep Learning? Probably all of it…

&gt; load a module with an incompatible licenseLoading any out-of-tree module taints the kernel, for example the vbox modules are GPL: <a href="https:&#x2F;&#x2F;archlinux.org&#x2F;packages&#x2F;community&#x2F;x86_64&#x2F;virtualbox-host-modules-arch&#x2F;" rel="nofollow">https:&#x2F;&#x2F;archlinux.org&#x2F;packages&#x2F;community&#x2F;x86_64&#x2F;virtualbox-h...</a>

For the uninitiated: If the linux kernel is asked to load a module with an incompatible license, it&#x27;s called &quot;tainted&quot;: <a href="https:&#x2F;&#x2F;www.kernel.org&#x2F;doc&#x2F;html&#x2F;latest&#x2F;admin-guide&#x2F;tainted-kernels.html" rel="nofollow">https:&#x2F;&#x2F;www.kernel.org&#x2F;doc&#x2F;html&#x2F;latest&#x2F;admin-guide&#x2F;tainted-k...</a>

Nvidia module does not taint kernel anymore!

Nope, but read this: <a href="https:&#x2F;&#x2F;blogs.gnome.org&#x2F;uraeus&#x2F;2022&#x2F;05&#x2F;11&#x2F;why-is-the-open-source-driver-release-from-nvidia-so-important-for-linux&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blogs.gnome.org&#x2F;uraeus&#x2F;2022&#x2F;05&#x2F;11&#x2F;why-is-the-open-so...</a>

&gt; 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?

The Steam Deck uses an AMD GPU, so it was probably the other way around. I&#x27;m betting this was partly done so nVidia GPUs can be used in similar devices going forward.

they are contributing to <a href="https:&#x2F;&#x2F;github.com&#x2F;Plagman&#x2F;gamescope&#x2F;pull&#x2F;454" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Plagman&#x2F;gamescope&#x2F;pull&#x2F;454</a> which is SteamOS session compositing window manager. so maybe in future Steam Deck will Nvidia tech.

I wonder what impact this will have on the SteamDeck if any.

No way they&#x27;re releasing CUDA or Nvidia RTX code. That&#x27;ll stay closed source (and I respect that)

I wonder if that means their userspace drivers will follow soon.

I remember reading an article where it was claimed that Nvidia successfully did a “counter hack” on that group, whatever that means.Considering this is coming well after the supposed deadline, I don’t think it’s related.

&gt;If this request is not met, on Friday we will release the complete Silicon, Graphics and Computer Chipset Files for all recent Nvidia GPUs.Since the deadline passed I guess Nvidia negotiated, or they were bluffing.

I don&#x27;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&#x27;t find the link but I believe this thing has been in the making for a long while[edit] found it: <a href="https:&#x2F;&#x2F;www.phoronix.com&#x2F;scan.php?page=news_item&amp;px=Big-New-Driver-Coming" rel="nofollow">https:&#x2F;&#x2F;www.phoronix.com&#x2F;scan.php?page=news_item&amp;px=Big-New-...</a>

This doesn&#x27;t actually solve the major standing issue with Nvidia&#x27;s drivers as far as I&#x27;m aware, because the biggest thorn has been the secretful FALCON units, and the code signing of firmware blobs that&#x27;s kept projects like nouveau from being able to gain traction.Remember, it isn&#x27;t enough that the kernel module is FOSS. The firmware is where the crux is.

Definitely. There are no coincidences in Nvidia strategy.

I wonder if it is the result of the LAPSUS$ hack. This was their statement from early March:&quot;After evaluating our position and Nvidia&#x27;s, we decided to add one more requirement.&quot;&quot;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.&quot;&quot;If this request is not met, on Friday we will release the complete Silicon, Graphics and Computer Chipset Files for all recent Nvidia GPUs.&quot;

They moved more function to the GPU firmware: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31346024" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31346024</a>

I am guessing the Nvidia is more okay with doing this because they have moved more functionality to the userspace components?

I&#x27;d be interested to know too. The hackers purportedly demanded release of the Nvidia drivers as open source:&gt; 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] <a href="https:&#x2F;&#x2F;www.theverge.com&#x2F;2022&#x2F;3&#x2F;4&#x2F;22962217&#x2F;nvidia-hack-lapsus-have-i-been-pwned-email-breach-password" rel="nofollow">https:&#x2F;&#x2F;www.theverge.com&#x2F;2022&#x2F;3&#x2F;4&#x2F;22962217&#x2F;nvidia-hack-lapsu...</a>

The datacenter focus here probably just means that $$$$ did the talking somewhere. AKA some large customer&#x2F;former customer&#x2F;potentially former customer said &quot;open source or else&quot; and they decided that having a couple people clean up, and push the special bits into the firmware&#x2F;etc was a good way to solve the problem and keep $ALTERNATIVE at bay for the next generation or two.

c&#x27;mon y&#x27;all. read the other threads before commetning. It&#x27;s not. <a href="https:&#x2F;&#x2F;blogs.gnome.org&#x2F;uraeus&#x2F;2022&#x2F;05&#x2F;11&#x2F;why-is-the-open-source-driver-release-from-nvidia-so-important-for-linux&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blogs.gnome.org&#x2F;uraeus&#x2F;2022&#x2F;05&#x2F;11&#x2F;why-is-the-open-so...</a>

Looking over the GitHub commit history of the two contributors on the repo, I’d say it’s a reaction.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.

My money is on the &quot;Steam-Deck Effect&quot;.

I wonder if this has been in the works for years, or if this is a reaction to the recent Lapsus hack.

That&#x27;s very different. The source code for the userspace portions of the MESA drivers for AMD&#x2F;Intel are released under a permissive licenses, so OpenBSD (and other BSDs) have been able to modify them to compile under their OS (and get those changes committed to the original tree). With NVIDIA, the userspace portions don&#x27;t use MESA, so would need some form of translation layer to work on an OS other than Linux.But, said translation layer would have limited scope; so is a lot more feasible than maintaining a general purpose translation layer indefinitely.

If the module can use MESA, good. If not, meh.&gt;. Adding enough just emulation for the userspace driver would be a lot easier than maintaining a complete linux emulator.OpenBSD it&#x27;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.

I wonder if this is related: <a href="https:&#x2F;&#x2F;www.eetimes.com&#x2F;wp-content&#x2F;uploads&#x2F;Nvidia-hack-security.png" rel="nofollow">https:&#x2F;&#x2F;www.eetimes.com&#x2F;wp-content&#x2F;uploads&#x2F;Nvidia-hack-secur...</a>

Wow! MIT is about as clean as you can go, with no real reserved advantage to dual license etc using Affero GPLv3 or similar. Not bad.

&gt; I like back-foot, underdog NVIDIA. Ascendent AMD hasn&#x27;t drawn my ire yet, let&#x27;s hope power corrupts slowly.That &quot;back-foot&quot; &quot;underdog&quot; nVidia has the edge in the video market still... and 3x the market cap of AMD.

Amd changed their windows drivers to not output video if it detects its running in a VM. Nvidia went the other way and stopped doing so.Both can&#x2F;could be bypassed with some libvirtd xml magic, but still. Nvidia seem to slowly stop being assholes, AMD started already.

Just had my first graphics stack issue since 2013 upgrading to Fedora 36 and was caught flat-footed. I&#x27;ve got multiple GPUs, so now I&#x27;ve got to figure out if it&#x27;s Wayland, amdgpu, nouveau (since unblacklisting), or dkms. &quot;Just working&quot; has made me lazy.

That might not even be overstatement. The last few big desktop linux crash-and-burns I&#x27;ve run into all had display drivers as a common component.I like back-foot, underdog NVIDIA. Ascendent AMD hasn&#x27;t drawn my ire yet, let&#x27;s hope power corrupts slowly.

&gt; It&#x27;s even licensed as MIT.Wouldn&#x27;t be the first time. The old 2D &quot;nv&quot; driver was part of X11, and maintained by Nvidia employees.The catch, besides it being 2D only, was the &quot;source code&quot; was actually somewhat obfuscated.

Had to do a few doubletakes on this, but even with the recent hacks and progress on NVIDIA releasing Tegra source code, I didn&#x27;t expect this for another few years.Holy shit.It&#x27;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.

Please change it back.  Nvidia was the official source and Phoronix is low-quality blogspam of dubious accuracy.

Uh why would you change from a good, official source to a worse rehash of the same stuff with less detail from Phoronix?I don&#x27;t even dislike Phoronix, but what was wrong with the first-party source?

Ok, we&#x27;ve changed to that from <a href="https:&#x2F;&#x2F;developer.nvidia.com&#x2F;blog&#x2F;nvidia-releases-open-source-gpu-kernel-modules&#x2F;" rel="nofollow">https:&#x2F;&#x2F;developer.nvidia.com&#x2F;blog&#x2F;nvidia-releases-open-sourc...</a> above. Thanks!Edit: ok, changed back

&gt; the user space stuff (OpenGL&#x2F;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 &quot;here&#x27;s how you dispatch PTX to the card&quot; layer and a &quot;here&#x27;s how you turn OGL&#x2F;Vulkan into PTX&quot; blob then the dispatch layer probably isn&#x27;t changing as much.(graphics doesn&#x27;t really use PTX but you get what I mean... dispatching compiled assembly and graphics API calls to the card.)It doesn&#x27;t help further the copyleft cause as much as if NVIDIA had open-sourced everything, of course, but from an end-user perspective of &quot;I don&#x27;t want my kernel updates to be tied to my driver release-cycle&quot; it should solve almost all of the problem?

Phoronix link about what this actually means:<a href="https:&#x2F;&#x2F;www.phoronix.com&#x2F;scan.php?page=article&amp;item=nvidia-open-kernel&amp;num=1" rel="nofollow">https:&#x2F;&#x2F;www.phoronix.com&#x2F;scan.php?page=article&amp;item=nvidia-o...</a>Main takeaways:- support for gaming workstation GPUs is alpha- the user space stuff (OpenGL&#x2F;Vulkan) is still closed source. (A LOT of heavy lifting is done here.)

That&#x27;s not really surprising when they are importing to a new repo and they aren&#x27;t sure there isnt anything confidential (or bad optics) in previous commits or message

from the article:&gt; With each new driver release, NVIDIA publishes a snapshot of the source code on GitHubThat definitely sounds like squashed commits will be the norm for now

According to README:&gt; There will likely only be one git commit per driver release.

I&#x27;m curious to see how they&#x27;ll manage updates, so far it&#x27;s one mega commit.&gt; Showing 2,519 changed files with 1,060,036 additions and 0 deletions.

This is well after the deadline iirc, and not the sort of thing that gets rushed.I doubt this is directly because of that.

it&#x27;s not at all. <a href="https:&#x2F;&#x2F;blogs.gnome.org&#x2F;uraeus&#x2F;2022&#x2F;05&#x2F;11&#x2F;why-is-the-open-source-driver-release-from-nvidia-so-important-for-linux&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blogs.gnome.org&#x2F;uraeus&#x2F;2022&#x2F;05&#x2F;11&#x2F;why-is-the-open-so...</a>

Likely very related, wasn&#x27;t this one of their exact demands? Looks like Nvidia caved haha.

&gt;I wonder how much LAPSUS$ hack has to do with it.Probably zero.1) There have been rumors about this for months2) The hacks only happened very recently, this certainly would have taken longer to do than that.

If I recall properly, the command circular buffers of 2^n bytes (&quot;queues&quot; in vulkan3d) are VRAM IOMMAP-ed (you just need atomic R&#x2F;W pointers for synchronization, see mathematically proven synchronization algorithms).
There is a &quot;GPU IRQ&quot; circular buffer of 2^n bytes coupled with PCIE MSIs (and I recall something about a hardware &quot;message box&quot;).
The &quot;thing&quot; is, for many of them, how to use those commands and how they are defined feels very weird (for instance the 3d&#x2F;compute pipeline registers programing).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&#x2F;compute pipeline programing is done from userspace via those circular buffers.If I am not too much mistaken, on lastest GPU &quot;everything&quot; 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 &quot;rdy&quot; at power up).

Do you have a reference for the AMD interface? I know it exists but don&#x27;t know where to find it.

The kernel modules are the first stage I guess, since a massive amount of hardware programing knowledge is in user space like with AMD&#x2F;intel GPUs.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.

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.

Nope, nouveau is still hosed because they&#x27;ve been blocked ny Nvidia&#x27;s secrutful FALCON&#x27;s which have the reclocking and power management API&#x27;s locked away behind proprietary firmware blobs.

It means Nouveau will finally can get good I think.

&gt; presumably works only with their own userspace drivers.For now, the plan is to replicate the way AMD driversWork, 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<a href="https:&#x2F;&#x2F;blogs.gnome.org&#x2F;uraeus&#x2F;2022&#x2F;05&#x2F;11&#x2F;why-is-the-open-source-driver-release-from-nvidia-so-important-for-linux&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blogs.gnome.org&#x2F;uraeus&#x2F;2022&#x2F;05&#x2F;11&#x2F;why-is-the-open-so...</a>

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.

Nouveau is still needed because Nvidia&#x27;s drivers do not conform to Linux kernel standards, so they can&#x27;t be upstreamed. Nouveau is conforming, so it still has a reason to exist. Fortunately Nouveau can more easily improve by using Nvidia&#x27;s now-open source as a reference.

From the linked article:&gt; The current codebase does not conform to the Linux kernel design conventions and is not a candidate for Linux upstream. [...]&gt; 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.

Currently no, the driver is alpha code at this point.But the goal is to create a complete open source stack like MESA for AMD.Also its only for Turing and newer (GTX 16XX+)
<a href="https:&#x2F;&#x2F;blogs.gnome.org&#x2F;uraeus&#x2F;2022&#x2F;05&#x2F;11&#x2F;why-is-the-open-source-driver-release-from-nvidia-so-important-for-linux&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blogs.gnome.org&#x2F;uraeus&#x2F;2022&#x2F;05&#x2F;11&#x2F;why-is-the-open-so...</a>

Hell is freezing?Serious, does it means we won&#x27;t need Nouveau anymore? How many and which binary blobs it still needs? Are they encrypted or require signing?

May be but atleast he wont show the middle finger

Ten bucks Linus will curse at them in the near future.

It could be quite interesting to outline just how far back in time this started (with lots of details), considering those demands to open-source certain code that were apparently made around March 3rd this year.My own motivation is to believe that NVidia isn&#x27;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&#x27;s attracted.Also, I found <a href="https:&#x2F;&#x2F;www.phoronix.com&#x2F;scan.php?page=news_item&amp;px=Big-New-Driver-Coming" rel="nofollow">https:&#x2F;&#x2F;www.phoronix.com&#x2F;scan.php?page=news_item&amp;px=Big-New-...</a> in another comment - 22 May to 12 May, that&#x27;s some serious stamina lol

I didn&#x27;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.

See the RedHat graphics director here: <a href="https:&#x2F;&#x2F;linuxactionnews.com&#x2F;240" rel="nofollow">https:&#x2F;&#x2F;linuxactionnews.com&#x2F;240</a>He says that Nvidia&#x27;s interest intensified in the last 3 months. Probably Steam Deck challenging their monopoly is making them uneasy.

Would love to hear from folks who worked on this!Was this an ongoing thing? Did it have to be pitched hard? What finally made the difference? I&#x27;m assuming here it&#x27;s not because of LAPSUS as some speculate. This seems like it must have been in the making for quite a while.

Wow, this is big for Linux &amp; Nvidea isn&#x27;t it?

Does this mean we get a bit closer to having native, kernel-level Optimus drivers for Linux?

Parent is talking about the Compute Module 4, which can plug into (among other things) a first party IO board that has a PCIe 1x slot. With a simple hardware mod (cut the slot connector, cut the GPU, use a riser, etc etc), any GPU can physically fit. He&#x27;s only gotten one to work so far though, an ancient ATI card. Lots of fun YouTube videos and GitHub issues about this if you search parent&#x27;s name or look at links in his profile.

Which ones are connectable to it? And does this rely on the &quot;replace the USB3 controller with a PCIe bridge&quot; hardware mod?

&lt;meta&gt;-F geerl: not disappointedThank you for the work you do, I&#x27;m going through your ssd on rpi4 today!

This early is a good time to also iron out some of the inevitable aarch64 bugs that have already been ironed out in other kernel drivers for AMD&#x2F;other stacks.

<a href="https:&#x2F;&#x2F;github.com&#x2F;geerlingguy" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;geerlingguy</a>

It… works. I&#x27;m typing this comment from a machine running the new FOSS drivers like a champ on KDE Plasma. Not that it is perfectly stable, but it definitely works.

Its a bit too early now isn&#x27;t it ?
The driver is still very alpha, and doesn&#x27;t support most display stuff.

With this announcement, I&#x27;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&#x27;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.

With this NVIDIA can move these things to the GPU firmware, making things like vGPU enablement harder.

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.<a href="https:&#x2F;&#x2F;www.ibtimes.com&#x2F;nvidia-geforce-graphics-card-virtualization-hacked-how-activate-vgpu-feature-3179008" rel="nofollow">https:&#x2F;&#x2F;www.ibtimes.com&#x2F;nvidia-geforce-graphics-card-virtual...</a>

I guess nobody bothered to add vulkan support due to almost unusable performance without reclocking. Hopefully some work will get started with this news!

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??<a href="https:&#x2F;&#x2F;mesamatrix.net&#x2F;" rel="nofollow">https:&#x2F;&#x2F;mesamatrix.net&#x2F;</a>

With the kernel driver open source + redistributeble firmware I guess the graphics APIs can be provided by mesa.

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 &quot;use VESA 2D&quot; 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 &quot;this == CUDA&quot; but this == decent kernel module drivers for the GPU.

Well, then... hopefully FreeBSD and illumos will finally start getting support for CUDA.

Anyone know if this makes it easy to hack in SR-IOV support for desktop class gpus?

I remember using that for a Geforce2 MX and the installer.People has no idea on what FREEDOM do you have if you aren&#x27;t bound to crappy licenses with Nvidia and CUDA for serious computing where you can be limited per core.

That&#x27;s an interesting cognitive dissonance that I&#x27;ve always been fascinated by. I&#x27;ve heard people criticize developers who release proprietary drivers for the linux kernel, but never those who release something dual licensed as GPL2&#x2F;MIT, or those who distribute a dual licensed GPL2&#x2F;MIT module as if it were solely under the MIT license; surely that would violate the Linux kernel&#x27;s GPL (in being a derivative work) as much a proprietary module would?

I&#x27;m not sure about the details, but to write a linux kernel module you must include some .h files under the GPL license. You really have to include it because linux ABI is intentionally not stable exactly to prevent proprietary abuse. So, AFAIK, every functional linux kernel driver must be released under the GPL.

Because to make a driver work with Linux you have to add Linux-specific code that typically uses Linux&#x27;s source code, and that combination of the driver and Linux-specific code could be considered a &quot;derivative&quot;.Note that the word &quot;derivative&quot; is used here as defined by the license, not in its plain English meaning.

&quot;Derivate&quot; I think here is red herring. The biggest problem is that the combination of kernel + nvidia modules could never be redistributed, which means that technically no distro should have been able to ship these drivers by default.

&gt; 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.* <a href="https:&#x2F;&#x2F;www.nvidia.com&#x2F;en-us&#x2F;drivers&#x2F;unix&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.nvidia.com&#x2F;en-us&#x2F;drivers&#x2F;unix&#x2F;</a>So how can it be a &#x27;derivative&#x27; of the GPL Linux if it it also used on non-GPL systems?

As far as I&#x27;m aware, since AMD took over, they&#x27;ve been fairly stable (although occasionally omitting support for the latest features until the next kernel release)

&gt; the open source ATI drivers were always a bit buggy and it wasn&#x27;t that easy getting them installed either.No. Once mainlined, you had to do absolutely nothing to get the hardware working.

If I remember correctly, the open source ATI drivers were always a bit buggy and it wasn&#x27;t that easy getting them installed either.  The tradeoff was always Nvidia: proprietary but works well, ATI: open but buggy.

Why not go for a 5700g? That would hopefully avoid you having to replace your motherboard.

&gt; I&#x27;m thinking about selling my 3700X and getting a 12th gen Intel with an integrated GPU (I don&#x27;t game and really couldn&#x27;t care less about fast GPUs).Don&#x27;t suppose you&#x27;re in Ireland&#x2F;UK&#x2F;EU? Looking at building a low&#x2F;mid-range gaming rig for a sibling, and a 3700X would fit fine if you&#x27;re looking to sell.

It’s pretty damn stunning how quite an AIO 2x 140mm cooler can be. And graphics cards with those big triple fans are silent until needed.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.

If you want to stick with AMD and don&#x27;t want to swap out the motherboard, then you&#x27;d probably just need to get an AMD CPU with on board graphics.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: <a href="https:&#x2F;&#x2F;www.androidauthority.com&#x2F;amd-cpu-guide-1222438&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.androidauthority.com&#x2F;amd-cpu-guide-1222438&#x2F;</a>In particular:<pre><code> 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)
</code></pre>
For example, some of my homelab servers use older AMD Athlon 200 GE as their CPUs, due to the fact that there are on board graphics and because the TDP is 35W, both saving electricity and also allowing me to use passive cooling (with just a large heatsink <a href="https:&#x2F;&#x2F;www.arctic.de&#x2F;en&#x2F;Alpine-AM4-Passive&#x2F;ACALP00022A" rel="nofollow">https:&#x2F;&#x2F;www.arctic.de&#x2F;en&#x2F;Alpine-AM4-Passive&#x2F;ACALP00022A</a>).For the Zen 2 series that your 3700X belongs to, you might want to look at this table: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;List_of_AMD_Ryzen_processors#APUs_3" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;List_of_AMD_Ryzen_processors#A...</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.

The 3700x with a GPU with a fan is going to be a lot easier to make silent than a 12th gen Intel is going to be.Also many GPUs support the fan turning off when idle.

&gt; I couldn&#x27;t find any single GPU able to drive 3840x1600 without a fan&gt; I don&#x27;t gameLet me help. <a href="https:&#x2F;&#x2F;www.ebay.com&#x2F;itm&#x2F;194948432276" rel="nofollow">https:&#x2F;&#x2F;www.ebay.com&#x2F;itm&#x2F;194948432276</a> that&#x27;s a full DP 1.2 port in there <a href="https:&#x2F;&#x2F;www.techpowerup.com&#x2F;gpu-specs&#x2F;sapphire-ultimate-r7-250.b2751" rel="nofollow">https:&#x2F;&#x2F;www.techpowerup.com&#x2F;gpu-specs&#x2F;sapphire-ultimate-r7-2...</a> so it&#x27;ll drive 3840 x 1600 up to 108 Hz even without custom mode shenanigans.

I bought some midrange AMD graphics card a few years back, picked for idle wattage, linux support and quiet cooling.The card isn&#x27;t silent, but it&#x27;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.)

&gt; 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&#x27;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&#x27;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 &quot;sleep&quot; doesn&#x27;t work correctly, failing to reinitialize the correct video mode when waking up. It&#x27;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&#x27;m thinking about selling my 3700X and getting a 12th gen Intel with an integrated GPU (I don&#x27;t game and really couldn&#x27;t care less about fast GPUs).

Thank you for bring back so many memories of learning the unnecessarily hard way.This is great news

On Debian I do: module-assistant build-install nvidiaAnd it works every time, but you do need to run it every time. There is a way to automate it on new kernel installs.&gt; 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 hadI always kept the previous version of the kernel and module in case of this.I&#x27;ve been recompiling my nvidia module each kernel release for over a decade and I&#x27;ve had no problems, you install the kernel, you install the nvidia module, and you reboot.

&gt; EDIT: Remember you had to recompile the shim at every kernel update and replaced &quot;module&quot; with &quot;driver&quot;.I haven&#x27;t bought NVIDIA since then

What do you mean with &quot;old times&quot;? :)That&#x27;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.

the old times is what precipitated linus to give nvidia the finger.

&gt; [...] you could end up without X11 and no way to easily run a browser or google about the problem you had.You don&#x27;t need X11 to run a browser. But you are right that it&#x27;s pretty inconvenient without.

For those who didn&#x27;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 &quot;module&quot; with &quot;driver&quot;.

How does what is being open-sourced differ from the proprietary binary modules?

This is the key paragraph in the article relevant to your point:<pre><code> This open-source kernel code is currently split into OS-agnostic and kernel interface layer components. This stems from NVIDIA&#x27;s proprietary driver on Linux largely being shared code across Windows &#x2F; Linux &#x2F; FreeBSD &#x2F; 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&#x27;s DAL&#x2F;DC originally had tough time upstreaming due to its numerous abstractions.</code></pre>

&gt; 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&#x27;s a huge first step, and in AMD&#x27;s case I think they eventually reworked it so that it could indeed be merged.

You want things to be &#x27;upstreamable&#x27; as they can be included in the default upstream kernel. If it gets included in Linus&#x27; git tree then keeping it working on future version of the kernel is much less hassle

Upstreamable means adding it to the official Linux source being distributed on linux.org.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.

&gt; What does &quot;upstreamable&quot; mean in this context? Is this good or bad?&quot;Upstream&quot; 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. &quot;Upstreaming&quot; is the process of getting your code included in these official releases. It&#x27;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&#x2F;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&#x27;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.

&#x27;Upstreamable&#x27; means that they send Linus a pull request, and Linus merges it into the kernel. It would then become part of Linux.It&#x27;s a negative that it&#x27;s not upstreamable. I wouldn&#x27;t go so far as to say it&#x27;s bad, but it&#x27;s less than good. That means you&#x27;ll continue to maintain a separate kernel module that&#x27;s rebuilt for each kernel.It would need to be modified to match the kernel&#x27;s coding standards and whatnot. Part of what makes linux such a strong thing is that you&#x27;re just not allowed to do certain things in the kernel. They won&#x27;t include ZFS in the kernel because it&#x27;s got its own entire vfs -- linux filesystems are only permitted to use linux&#x27;s vfs, and if you need vfs changes to make it work, you modify the &#x27;one true&#x27; vfs. They didn&#x27;t include the original AMD Radeon driver because it had its own hardware abstraction layer; you&#x27;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&#x27;s not immediately clear to me how much work it will take to get the driver into the kernel. Hopefully it won&#x27;t be a lot of work, but it&#x27;s possible that it would require basically rewriting it from scratch. It&#x27;s at least written almost entirely in C, so that&#x27;s a good start.Regardless, this is tremendously good news.

&gt; This is not upstreamable in its current formWhat does &quot;upstreamable&quot; 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?

Has any rationale been provided around the blob being closed?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?

I expect once Nouveau will have reclocking ironed out, there will be an effort to implement Vulkan on top of it in Mesa. OpenGL is already available.That will allow avoiding Nvidia blob except for the firmware.

I came here to say that. This isn&#x27;t an NVIDIA commitment to open source; it is a slap in the face. Rather than open sourcing the drivers, they are patching the kernel to fit the needs of their proprietary driver. Note that I&#x27;m not against proprietary software, however, title of this post was super misleading and NVIDIA needs to grow up and work on an open-source driver. The world will NOT change for them.

That&#x27;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&#x27;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&#x2F;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.

While this is not as good as an open-source GPU driver, it is nonetheless a significant progress, which cannot be dismissed as useless.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&#x2F;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.

It is not, but I think it removes a giant blocker for a truly OSS driver with Mesa&#x2F;nouveau.

... and like any new software from NVIDIA it only supports the most recent generation of cards.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&#x27;s been outright cruel.

It takes time for Nvidia to become open-source friendly. Still a good move.Hopefully the GPU driver is next in their open-source roadmap.

Sadly, it&#x27;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.

(1) No, it&#x27;s unambiguously &quot;meh&quot; newsNvidia have merely moved their giant closed source drivers into &quot;firmware&quot; - 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&#x27;s it.

1) This is unambiguously Good News2) 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&#x27;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.

Probably all their &quot;enterprise&quot; feature lockouts(vgpu etc..) are in the gigantic firmware that&#x27;s loaded into GSP. But things that matter to desktop users probably aren&#x27;t going to be locked out this way.

It sounds like this &quot;GSP&quot; lets them binary blob their &quot;secret sauce&quot; on the controller itself, so the rest of the driver can be open source now.

I did a double take because the title is almost clickbait for us desktop Linux users, and immediately wondered &quot;what&#x27;s the catch?&quot;. It&#x27;s a significant catch, but also a significant step in the right direction.

<a href="https:&#x2F;&#x2F;youtu.be&#x2F;_36yNWw_07g" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;_36yNWw_07g</a> Linus expressing his deepest gratitude.

Yes, Turing or newer is a hard requirement.

I didn’t see anything for Pascal GPUs, are they left out?

I thought they had open source CUDA kernels for a minute..

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&#x27;s what Mesa is here for.

&gt; Stable open source support for GTX 10xx GPU users may come later.Nope, Turing or later gen GPU is a hard requirement.

ctrl+f binary, tx this is the answer I was looking for. The binary is still in linux-firmware similar to intel drivers

The reason for this is because NVIDIA&#x27;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&#x27;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&#x27;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&#x27;s talking about.

&gt; 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 &amp; simplifying the language here: sounds like GTX 10xx GPU users (Pascal architecture, e.g. 1070&#x2F;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.

You&#x27;re looking at the wrong thing. <a href="https:&#x2F;&#x2F;github.com&#x2F;NVIDIA&#x2F;open-gpu-kernel-modules&#x2F;tree&#x2F;main&#x2F;src" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;NVIDIA&#x2F;open-gpu-kernel-modules&#x2F;tree&#x2F;main&#x2F;...</a> contains the largest parts of the driver.

It seems the modules bridge the kernel with the driver [1], so it is this part that is GPL&#x2F;MIT, the driver itself is still a binary blob. 
AMD probably does the same? Correct me if I&#x27;m wrong.[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;NVIDIA&#x2F;open-gpu-kernel-modules&#x2F;tree&#x2F;main&#x2F;kernel-open" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;NVIDIA&#x2F;open-gpu-kernel-modules&#x2F;tree&#x2F;main&#x2F;...</a>

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?

Thank you nvidia, we&#x27;ve been waiting for this and you finally came through for us!

&gt;in middle schoolHaha that&#x27;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!

They can finally close that support ticket!

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.It’s been a long time coming lol.[1] <a href="https:&#x2F;&#x2F;www.spinics.net&#x2F;lists&#x2F;xf-xpert&#x2F;msg04601.html" rel="nofollow">https:&#x2F;&#x2F;www.spinics.net&#x2F;lists&#x2F;xf-xpert&#x2F;msg04601.html</a>

Thanks for clearing that up, for a second I thought nVidia was finally Linux viable.

&gt;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.

Are they? I thought the “OS-agnostic” part was historically only available as a binary. Maybe that changed since last time I looked.On quick inspection, this is a complete, MIT-licensed kernel driver.

The same could be said of a lot of Nvidia IP which was leaked a few months ago.But this is different, it&#x27;s voluntary.

This isn&#x27;t the same as the source previously provided with the drivers. This is a completely new kernel module.

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.

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.

<a href="https:&#x2F;&#x2F;github.com&#x2F;NVIDIA&#x2F;open-gpu-kernel-modules#supported-target-cpu-architectures" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;NVIDIA&#x2F;open-gpu-kernel-modules#supported-...</a>&quot;Currently, the kernel modules can be built for x86_64 or aarch64.&quot;

Nvidia has been providing ARM drivers for a little while and they work on Ampere Altra.

May this enables the possibility of compiling NVIDIA drivers for ARM-based PCs?

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?

I don&#x27;t normally curse on HN but I think I speak for all of us when I sayFucking finally.

&gt; The closed source driver still exists but there will hopefully be a completely open source stack (Nouveau++?) For nvidia.I can only hope they change name to aidivn, like any sane driver should.

OpenCL, for one.If you don&#x27;t care about that, you can run pretty much anything else and performance is great.

AMD proprietary driver actually has only few proprietary bits. Other than OpenCL that was already mentioned there are:* Proprietary shader compiler that can also be used for Vulkan* Legacy OpenGL driver optimized for closed-source workstation apps

For the most part, it&#x27;s just specific support for specific workstation applications that AMD can&#x27;t release publicly due to some contractual reasons or that those specific changes would be a detriment to a general selection applications. There are a few OpenGL features in there not in the open driver. There&#x27;s also the DirectGMA thing for having hardware DMA directly to and from the GPU without CPU involvement.The latter I wish was just a general purpose feature now that things like resizable bar are seeing general support in the consumer space.

I&#x27;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?

It will probably end up like how AMD cards work.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.<a href="https:&#x2F;&#x2F;blogs.gnome.org&#x2F;uraeus&#x2F;2022&#x2F;05&#x2F;11&#x2F;why-is-the-open-source-driver-release-from-nvidia-so-important-for-linux&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blogs.gnome.org&#x2F;uraeus&#x2F;2022&#x2F;05&#x2F;11&#x2F;why-is-the-open-so...</a>

Wow! I literally never thought I&#x27;d see the day.I&#x27;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&#x27;t overstate how huge this is!Great work Nvidia, seriously. It does look like it&#x27;s not perfect, but damn it&#x27;s a great step.

This is great. Anyone know how&#x2F;if this will&#x2F;does impact laptops with nvidia dGPU?

Will Linus revisit his rejection of Nvidia integration?

You might be curious about Kompute++.But anyway, the user-space stuff is still the same. This only affects the kernel modules.

Can this be used with CUDA for GPGPU or is it somehow only relevant for graphics?

Public post by nVidia: <a href="https:&#x2F;&#x2F;developer.nvidia.com&#x2F;blog&#x2F;nvidia-releases-open-source-gpu-kernel-modules&#x2F;" rel="nofollow">https:&#x2F;&#x2F;developer.nvidia.com&#x2F;blog&#x2F;nvidia-releases-open-sourc...</a>

No, there&#x27;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&#x27;s been a problem for reactos with windows leaks, and it would be orders of magnitude worse for NVIDIA&#x2F;AMD.

Is this connected to the hack&#x2F;leak where the hackers requested this very move?WE REQUEST THAT NVIDIA COMMITS TO COMPLETELY OPEN-SOURCE (AND DISTRIBUTE UNDER A FOSS LICENSE) THEIR GPU DRIVERS”<a href="https:&#x2F;&#x2F;www.theverge.com&#x2F;2022&#x2F;3&#x2F;1&#x2F;22957212&#x2F;nvidia-confirms-hack-proprietary-information-lapsus" rel="nofollow">https:&#x2F;&#x2F;www.theverge.com&#x2F;2022&#x2F;3&#x2F;1&#x2F;22957212&#x2F;nvidia-confirms-h...</a>

Never though this would happen in my lifetime.

Oh frabjous day! I have been waiting for this for literal decades.

And just like that my next gpu will probably be NVIDIA. AMD&#x27;s recent prices have made nvidia look like a better option and the only thing holding me back was amd&#x27;s amazing open source drivers and the options that came with. If nvidia&#x27;s drivers become comparable or are well on their way then they would be the obvious choice in today&#x27;s market.

This is what happens when you don&#x27;t just give up and &quot;be pragmatic&quot;. Kudos to NVidia for coming to the table, and I look forward to seeing more of this sort of thing.

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&#x27;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.

Looking forward to a day when out of the box Nvidia and AMD GPUs just work on Linux at fullpower and features.

I believe everyone is the comments are like, &quot;Omg! They finally took us seriously telling they are horrible at writing drivers for Linux&quot;. Good job Nvida

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&#x27;t split access to the single GPU among multiple VMs.

AMD and Intel both have open source video drivers and I really doubt anyone has cloned them.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&#x27;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&#x27;t a concern.

You mean, like Intel GPU drivers with just the libre free-as-in-freedom kernel and MESA? Blender? Krita? Cinelerra-CV?
Darktable? ImageMagick? FFMPEG? KVM&#x2F;Qemu? Most programming languages and frameworks? Clang&#x2F;LLVM?WTF are you talking about?If any, science today it&#x27;s made thanks to FLOSS software, propietary software it&#x27;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&#x2F;experiment it&#x27;s replicated, yo get the same environment no matter where and how.
That&#x27;s the difference.

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&#x27;d significantly reduce the value of what they&#x27;d built (to them).Really, I don&#x27;t get why so many Linux users ask questions like this. Most software is proprietary because it costs money to develop. This site we&#x27;re talking on isn&#x27;t open source. Windows isn&#x27;t. macOS &#x2F; iOS isn&#x27;t. Games generally aren&#x27;t. Google isn&#x27;t. Azure&#x2F;Bing aren&#x27;t. Open source is the exception, not the norm.

Probably their management is too old fashioned to get this.

I&#x27;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?

The bits that implement the userland graphics libraries are closed source, unlike Mesa. So this is still useless, but don&#x27;t get me wrong... I&#x27;ll take it, but I&#x27;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.

As predicted 3 months ago ;)<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30471005" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30471005</a>

<a href="https:&#x2F;&#x2F;blogs.gnome.org&#x2F;uraeus&#x2F;2022&#x2F;05&#x2F;11&#x2F;why-is-the-open-source-driver-release-from-nvidia-so-important-for-linux&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blogs.gnome.org&#x2F;uraeus&#x2F;2022&#x2F;05&#x2F;11&#x2F;why-is-the-open-so...</a>
<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31345835" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31345835</a>

Finally some good news for free software \o&#x2F;

What does it mean? I don&#x27;t know anything about it? Why is it good news?

- Stock market crashing
- Crypto being an absolute dumpster fire
- Nvidia doing something to support LinuxCatastrophe is upon us!

woah.... that only took like forever. anyhow - good job

we regret to inform you...<a href="https:&#x2F;&#x2F;git.kernel.org&#x2F;pub&#x2F;scm&#x2F;linux&#x2F;kernel&#x2F;git&#x2F;firmware&#x2F;linux-firmware.git&#x2F;tree&#x2F;amdgpu" rel="nofollow">https:&#x2F;&#x2F;git.kernel.org&#x2F;pub&#x2F;scm&#x2F;linux&#x2F;kernel&#x2F;git&#x2F;firmware&#x2F;lin...</a>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&#x27;s.

watch out the fine print though:<a href="https:&#x2F;&#x2F;twitter.com&#x2F;marcan42&#x2F;status&#x2F;1524615058688724992" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;marcan42&#x2F;status&#x2F;1524615058688724992</a>34MB firmwareGood, but I&#x27;ll try to stick with AMD. If only AMD&#x27;s opencl support was better...

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

This is such good news... I hope we see &#x27;real world improvements soon&#x27; !The amount of time, I was &#x27;sucked&#x27; 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 !

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&#x27;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.

That makes ThinkPads with Linux look much different than before compared to MacBooks with macOS. (And save a lot of update&#x2F;re-configure&#x2F;re-install cycles...)

I wonder how much of this decision was due to the hack leaking everything they had.

Nvidia releases open-source GPU kernel modules