[HN Gopher] Nvidia releases open-source GPU kernel-modules
___________________________________________________________________
Nvidia releases open-source GPU kernel-modules
Author : ghishadow
Score : 825 points
Date : 2022-05-11 19:59 UTC (3 hours ago)
(HTM) web link (www.phoronix.com)
(TXT) w3m dump (www.phoronix.com)
| comandillos wrote:
| May this enables the possibility of compiling NVIDIA drivers for
| ARM-based PCs?
| adolph wrote:
| https://github.com/NVIDIA/open-gpu-kernel-modules#supported-...
|
| "Currently, the kernel modules can be built for x86_64 or
| _aarch64_. "
| wmf wrote:
| Nvidia has been providing ARM drivers for a little while and
| they work on Ampere Altra.
| messe wrote:
| Had to do a few doubletakes on this, but even with the recent
| hacks and progress on NVIDIA releasing Tegra source code, I
| didn't expect this for another few years.
|
| Holy shit.
|
| It's even licensed as MIT.
|
| Even OpenBSD could conceivably port this with enough manpower.
| Adding enough just emulation for the userspace driver would be a
| lot easier than maintaining a complete linux emulator.
|
| This is one of the biggest things to happen to hardware support
| for open source OSes in well over a decade.
| samstave wrote:
| ELI5: ? (dont have a formulated question ; ELI5 impact plz)
| paisawalla wrote:
| Nvidia have always shipped closed-source drivers, despite AMD
| and Intel providing open source drivers for their GPUs. This
| made the experience on Linux second class to Windows, where
| while also closed source, at least you knew that bugs would
| probably get fixed. Various non-core features simply wouldn't
| have support on Linux, e.g. Optimus. Also, shipping closed
| source binaries would limit which kernel you could run to
| supported versions.
|
| Lastly, of course, this opens the way to non-Linux OSes
| receiving support as well.
|
| If you just search the web for "Nvidia issues Linux" you'll
| see quite a few complaints. Particularly from people who have
| obscure configurations -- they pretty much had no chance of
| getting anything to work.
| bayindirh wrote:
| > where while also closed source, at least you knew that
| bugs would probably get fixed.
|
| Yeah, I waited _just 18 months_ (IIRC) for proper
| DisplayPort DPMS signalling, so my monitor can sleep.
|
| Linux driver bugs get fixed, albeit accidentally.
| messe wrote:
| I think the GP meant the windows drivers would be fixed;
| not the linux drivers.
| lucideer wrote:
| This is a good technical summary of the impact but I think
| misses the somewhat emotive history here.
|
| See things like this infamous clip from Torvalds[0] for
| more context on the community sentiment around nvidia in
| general.
|
| [0] https://www.youtube.com/watch?v=IVpOyKCNZYw
| anthk wrote:
| If the module can use MESA, good. If not, meh.
|
| >. 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.
| messe wrote:
| That's very different. The source code for the userspace
| portions of the MESA drivers for AMD/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'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.
| onphonenow wrote:
| 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.
| moffkalast wrote:
| I wonder if this is related: https://www.eetimes.com/wp-
| content/uploads/Nvidia-hack-secur...
| [deleted]
| jjoonathan wrote:
| That might not even be overstatement. The last few big desktop
| linux crash-and-burns I've run into all had display drivers as
| a common component.
|
| I like back-foot, underdog NVIDIA. Ascendent AMD hasn't drawn
| my ire yet, let's hope power corrupts slowly.
| lawl wrote:
| 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/could be bypassed with some libvirtd xml magic, but
| still. Nvidia seem to slowly stop being assholes, AMD started
| already.
| namlem wrote:
| The cycle continues
| mlyle wrote:
| > I like back-foot, underdog NVIDIA. Ascendent AMD hasn't
| drawn my ire yet, let's hope power corrupts slowly.
|
| That "back-foot" "underdog" nVidia has the edge in the video
| market still... and 3x the market cap of AMD.
| SemanticStrengh wrote:
| APUs are eating the market of novideo, see e.g. the
| performance of the M1 iGPU
| [deleted]
| orra wrote:
| > It's even licensed as MIT.
|
| 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.
| NexRebular wrote:
| Well, then... hopefully FreeBSD and illumos will finally start
| getting support for CUDA.
| smw wrote:
| Anyone know if this makes it easy to hack in SR-IOV support for
| desktop class gpus?
| pixelmonkey wrote:
| > In this open-source release, support for GeForce and
| Workstation GPUs is alpha quality. GeForce and Workstation users
| can use this driver on Turing and NVIDIA Ampere architecture GPUs
| to run Linux desktops and use features such as multiple displays,
| G-SYNC, and NVIDIA RTX ray tracing in Vulkan and NVIDIA OptiX.
| Users can opt in using the kernel module parameter
| NVreg_EnableUnsupportedGpus as highlighted in the documentation.
| More robust and fully featured GeForce and Workstation support
| will follow in subsequent releases and the NVIDIA Open Kernel
| Modules will eventually supplant the closed-source driver.
| Customers with Turing and Ampere GPUs can choose which modules to
| install. Pre-Turing customers will continue to run the closed
| source modules.
|
| Translating & simplifying the language here: sounds like GTX 10xx
| GPU users (Pascal architecture, e.g. 1070/1080) will stick with
| closed source for now, but RTX 20xx GPU users (Turing
| architecture, e.g. 2080) and RTX 30xx GPU users (Ampere
| architecture, e.g. 3080) will have the option to opt-in to the
| open source kernel module. Stable open source support for GTX
| 10xx GPU users may come later.
| kaladin-jasnah wrote:
| The reason for this is because NVIDIA's Turing and above GPUs
| use a new microcontroller called the GSP, which is RISC-V
| based. From my understanding, NVIDIA has offloaded their
| proprietary IP from the closed-source driver to the GSP
| firmware (and not the older microcontroller present on Pascal
| and lower). This is why `gsp.bin` exists in `linux-firmware`
| now, and the FOSS driver targets the GSP (because now the
| proprietary stuff isn't in the kernel driver but rather a
| RISC-V ELF binary that runs on the GPU), not the older
| controller.
| jabl wrote:
| > Stable open source support for GTX 10xx GPU users may come
| later.
|
| Nope, Turing or later gen GPU is a hard requirement.
| akselmo wrote:
| This year just keeps getting more weird
| intsunny wrote:
| Phoronix link about what this actually means:
|
| https://www.phoronix.com/scan.php?page=article&item=nvidia-o...
|
| Main takeaways:
|
| - support for gaming workstation GPUs is alpha
|
| - the user space stuff (OpenGL/Vulkan) is still closed source. (A
| LOT of heavy lifting is done here.)
| dang wrote:
| Ok, we've changed to that from
| https://developer.nvidia.com/blog/nvidia-releases-open-sourc...
| above. Thanks!
| InitEnabler wrote:
| Wow. Am I dreaming? That's great.
| anonymousDan wrote:
| Can this be used with CUDA for GPGPU or is it somehow only
| relevant for graphics?
| kodah wrote:
| AYYYYYY
|
| Shout out to nvidia for this.
| marius_k wrote:
| nvidia, fuck you no more!
| jzox wrote:
| Hopefully Linus concurs
| voldacar wrote:
| 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?
| zekrioca wrote:
| It seems the modules bridge the kernel with the driver [1], so it
| is this part that is GPL/MIT, the driver itself is still a binary
| blob. AMD probably does the same? Correct me if I'm wrong.
|
| [1] https://github.com/NVIDIA/open-gpu-kernel-
| modules/tree/main/...
| puffoflogic wrote:
| You're looking at the wrong thing.
| https://github.com/NVIDIA/open-gpu-kernel-modules/tree/main/...
| contains the largest parts of the driver.
| marcodiego wrote:
| For those who didn't use Nvidia on linux in the old times:
|
| The driver was a proprietary binary. Since a kernel module
| requires interfacing with the kernel API, it could be considered
| a derivative work and a breach of the GPL license. So, Nvidia
| provided a small open source shim which interfaced between the
| kernel and the proprietary module.
|
| You had to compile that shim yourself with the right arcane
| command line incantations and if you did anything wrong, missed
| the right packages or had an incompatible user space, including
| libs and compiler, you could end up without X11 and no way to
| easily run a browser or google about the problem you had. You had
| to do it EVERY FUCKING TIME YOU UPDATED THE KERNEL!
|
| It was still possible to edit xorg.conf or, if you were older,
| xf86config by hand to fix it and use the VESA driver, but it was
| very inconvenient. It became more reliable over the time and even
| fully automated with DKMS, but I hated them for it.
|
| I used and recommended ATI and INTEL for most of the people I
| could for a long time because of this.
|
| I was from a time when It was possible to use 3D acceleration on
| linux with 3dfx with fully open source drivers (I think), giving
| you a cheap UNIX-like graphical workstation with OpenGL support.
| When Nvidia bought 3dfx and simply killed their drivers, my hate
| became specially strong.
|
| EDIT: Remember you had to recompile the shim at every kernel
| update and replaced "module" with "driver".
| throw0101a wrote:
| > _The module was a proprietary binary. Since a kernel module
| requires interfacing with the kernel API, it could be
| considered a derivative work and a breach of the GPL license._
|
| I never quite understood this logic: the same (?) binary blob
| is used for the FreeBSD and Solaris drivers.
|
| * https://www.nvidia.com/en-us/drivers/unix/
|
| So how can it be a 'derivative' of the GPL Linux if it it also
| used on non-GPL systems?
| messe wrote:
| That's an interesting cognitive dissonance that I've always
| been fascinated by. I've heard people criticize developers
| who release proprietary drivers for the linux kernel, but
| never those who release something dual licensed as GPL2/MIT,
| or those who distribute a dual licensed GPL2/MIT module as if
| it were solely under the MIT license; surely that would
| violate the Linux kernel's GPL (in being a derivative work)
| as much a proprietary module would?
| marcodiego wrote:
| I'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.
| amelius wrote:
| APIs and ABIs should be open. GPL taking a different stance
| here is not helping anyone.
| marcodiego wrote:
| The point is: if you want to include a GPL licensed
| header, your code must comply with its license. Your
| opinion on the GPL is an entirely different matter.
| my123 wrote:
| btw for the Oracle vs Google lawsuit, OpenJDK was
| licensed as GPLv2. It was very much a GPL (purported)
| violation case.
| pornel wrote:
| Because to make a driver work with Linux you have to add
| Linux-specific code that typically uses Linux's source code,
| and that combination of the driver and Linux-specific code
| could be considered a "derivative".
|
| Note that the word "derivative" is used here as defined by
| the license, not in its plain English meaning.
| throw0101a wrote:
| Linus Torvalds: 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.
|
| * https://yarchive.net/comp/linux/gpl_modules.html
|
| Then you have things like (Open)ZFS and DTrace.
| puffoflogic wrote:
| > don't depend on any special Linux behaviour.
|
| This is the key point, and it is nearly impossible for
| firmware blobs to depend on any OS behavior, let alone
| "special Linux behavior". The only way they could do so
| is via the open-source part, so it should be easy enough
| to check that.
| messe wrote:
| You quickly get into something similar the ship of theseus
| (or Trigger's broom) argument. You write some code that
| must link to a GPL library to functon; that code is now GPL
| because it's a derivative work of the library.
|
| 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?
| pornel wrote:
| Your original code is never a derivative work. You retain
| copyright to the code you wrote yourself, even if it's
| combined with GPL later. GPL even contains this
| interesting clause:
|
| > _You are not required to accept this License, since you
| have not signed it._
|
| So to answer your question: no, unless you've copied bits
| of GPL library into your code (or similar that would be
| judged as a copyright violation).
|
| There's also a crappy situation of Oracle vs Google that
| made APIs copyrightable, so now it's not entirely clear
| if your code + your rewrite of library is still yours if
| it uses an API of the GPL library.
| messe wrote:
| > Your original code is never a derivative work[...]
|
| > > You are not required to accept this License, since
| you have not signed it.
|
| > So to answer your question: no, unless you've copied
| bits of GPL library into your code (or similar that would
| be judged as a copyright violation).
|
| Actually that clears a lot up for me, and I'd have
| considered myself reasonably knowledgeable when it comes
| to copyright in general; I think I had a few conflicting
| ideas about what it means to be an original work. Thank
| you.
| bogwog wrote:
| I'm not a lawyer, but my understanding is that the GPL
| requires you to make source available upon request to
| users of your software.
|
| So I guess if someone asks you for the source code, you
| can require them to prove that they actually have a copy
| of the GPL version, and not the new one.
| adastra22 wrote:
| The license is abundantly clear about this and answers
| all your questions.
|
| It matters who is doing the rewriting and how they got
| the code in the first place.
| messe wrote:
| I think one of the matters that confused me about it was
| the CLISP question. IIRC, CLISP linked to readline, but
| was released under a non-GPL license.
|
| RMS contacted them, and asked them to relicense. They
| suggested either reimplementing a stub readline-library,
| or rewriting their line editing code against another lib
| instead. RMS insisted that they would still be a GPL-
| derivative, resulting in the current license situation.
|
| I may be misremembering the recount of this, as this was
| way before my time.
| adastra22 wrote:
| RMS may have believed or wanted that, but it is my
| understanding (IANAL!) that the case law has been settled
| differently. If you are found in violation of the GPL due
| to a dependency you weren't aware was released under the
| GPL, you can fix that violation by rewriting your
| application to avoid the GPL dependency.
|
| CLISP et al cannot be forced to distribute their code
| under the GPL. It's their code and their choice; contract
| law cannot compel someone who has never entered into the
| contract to do something against their will -- CLISP
| didn't knowingly distribute GPL code, so that
| distribution doesn't trigger acceptance of the GPL terms.
| They just have to make the situation right once they're
| made aware of the violation.
| AshamedCaptain wrote:
| "Derivate" 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.
| anthk wrote:
| I remember using that for a Geforce2 MX and the installer.
|
| People has no idea on what FREEDOM do you have if you aren't
| bound to crappy licenses with Nvidia and CUDA for serious
| computing where you can be limited per core.
| frostwarrior wrote:
| Those were simpler times
| alksjdalkj wrote:
| If I remember correctly, the open source ATI drivers were
| always a bit buggy and it wasn't that easy getting them
| installed either. The tradeoff was always Nvidia: proprietary
| but works well, ATI: open but buggy.
| messe wrote:
| As far as I'm aware, since AMD took over, they've been fairly
| stable (although occasionally omitting support for the latest
| features until the next kernel release)
| dralley wrote:
| IIRC were some problems with the Linux drivers for Navi 1.0
| that continued for about a year after launch. Supposedly
| those have been fixed.
|
| My Vega 56 has been perfectly stable and trouble-free for
| years.
| marcodiego wrote:
| > the open source ATI drivers were always a bit buggy and it
| wasn't that easy getting them installed either.
|
| No. Once mainlined, you had to do absolutely nothing to get
| the hardware working.
| chlorion wrote:
| The part about them being buggy is definitely true.
|
| 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.
| Shared404 wrote:
| Just bought a 6600XT, and it's been great.
|
| Literally just plugged it in and installed the driver
| packages I didn't on initial setup, on most distros it
| would've literally been plug and play.
| marcodiego wrote:
| About them being buggy, I won't discuss. But you didn't
| have to do anything to even get them installed.
| eointierney wrote:
| Thank you for bring back so many memories of learning the
| unnecessarily hard way.
|
| This is great news
| Vladimof wrote:
| > EDIT: Remember you had to recompile the shim at every kernel
| update and replaced "module" with "driver".
|
| I haven't bought NVIDIA since then
| [deleted]
| ars wrote:
| On Debian I do: module-assistant build-install nvidia
|
| And it works every time, but you do need to run it every time.
| There is a way to automate it on new kernel installs.
|
| > missed the right packages or had an incompatible user space,
| including libs and compiler, you could end up without X11 and
| no way to easily run a browser or google about the problem you
| had
|
| I always kept the previous version of the kernel and module in
| case of this.
|
| I've been recompiling my nvidia module each kernel release for
| over a decade and I've had no problems, you install the kernel,
| you install the nvidia module, and you reboot.
| TacticalCoder wrote:
| > I used and recommended ATI and INTEL for most of the people I
| could for a long time because of this.
|
| Same here but recently I somehow got a 3700X and there's no
| integrated GPU so I had to look for a GPU. I like my PC not
| just quiet but nearly silent, so a GPU with a fan was a big no-
| no. I couldn't find any single GPU able to drive 3840x1600
| without a fan... Except for a NVidia one. Of course the
| proprietary Linux drivers are somehow buggy: the "sleep"
| doesn't work correctly, failing to reinitialize the correct
| video mode when waking up. It's always, always, always the same
| with NVidia GPUs on Linux. Thankfully I can switch to tty2,
| then back to graphical mode but I hate the inconvenience.
|
| I'm thinking about selling my 3700X and getting a 12th gen
| Intel with an integrated GPU (I don't game and really couldn't
| care less about fast GPUs).
| KronisLV wrote:
| If you want to stick with AMD and don't want to swap out the
| motherboard, then you'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:
| 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 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 https://www.arctic.de/en/Alpine-
| AM4-Passive/ACALP00022A).
|
| For the Zen 2 series that your 3700X belongs to, you might
| want to look at this table: https://en.wikipedia.org/wiki/Lis
| t_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.
| kd913 wrote:
| Why not go for a 5700g? That would hopefully avoid you having
| to replace your motherboard.
| LtdJorge wrote:
| Exactly
| messe wrote:
| > 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).
|
| 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.
| chx wrote:
| > I couldn't find any single GPU able to drive 3840x1600
| without a fan
|
| > 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.
| kllrnohj wrote:
| 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.
| RussianCow wrote:
| I was about to post this. The fans on my AMD RX 580 never
| turn on unless I'm gaming or doing some crazy WebGL stuff.
| I can only imagine that newer ones are even more efficient
| in this regard.
| SV_BubbleTime wrote:
| 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.
| pmoriarty wrote:
| 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?
| wmf wrote:
| That's called Nouveau.
| 8organicbits wrote:
| I'm curious to see how they'll manage updates, so far it's one
| mega commit.
|
| > Showing 2,519 changed files with 1,060,036 additions and 0
| deletions.
| bawolff wrote:
| That's not really surprising when they are importing to a new
| repo and they aren't sure there isnt anything confidential (or
| bad optics) in previous commits or message
| zokier wrote:
| from the article:
|
| > With each new driver release, NVIDIA publishes a snapshot of
| the source code on GitHub
|
| That definitely sounds like squashed commits will be the norm
| for now
| GlitchMr wrote:
| According to README:
|
| > There will likely only be one git commit per driver release.
| sylware wrote:
| The kernel modules are the first stage I guess, since a massive
| amount of hardware programing knowledge is in user space like
| with AMD/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.
| dralley wrote:
| >I wonder how much LAPSUS$ hack has to do with it.
|
| 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.
| moffkalast wrote:
| Likely very related, wasn't this one of their exact demands?
| Looks like Nvidia caved haha.
| Shared404 wrote:
| This is well after the deadline iirc, and not the sort of
| thing that gets rushed.
|
| I doubt this is directly because of that.
| umanwizard wrote:
| How does what is being open-sourced differ from the proprietary
| binary modules?
| zamadatix wrote:
| 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.
| mjg59 wrote:
| 1) This is unambiguously Good News
|
| 2) This is not upstreamable in its current form (nvidia admit
| this in their press release)
|
| 3) In an ideal world, nouveau (the open source driver for nvidia
| hardware) would be able to target this kernel code. Right now
| though there's no commitment for any sort of stable userland ABI,
| and that makes that difficult (moving to a new driver version may
| break interfaces that nouveau uses)
|
| 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.
| [deleted]
| marcodiego wrote:
| Hell is freezing?
|
| 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?
| gary_0 wrote:
| Nouveau is still needed because Nvidia's drivers do not conform
| to Linux kernel standards, so they can't be upstreamed. Nouveau
| is conforming, so it still has a reason to exist. Fortunately
| Nouveau can more easily improve by using Nvidia's now-open
| source as a reference.
| verst wrote:
| From the linked article:
|
| > 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.
| dzogchen wrote:
| It means Nouveau will finally can get good I think.
| salawat wrote:
| Nope, nouveau is still hosed because they've been blocked ny
| Nvidia's secrutful FALCON's which have the reclocking and
| power management API's locked away behind proprietary
| firmware blobs.
| kaladin-jasnah wrote:
| This new driver targets GPUs with FALCON, and nouveau will
| be able to control it, as FALCON is GSP (https://www.phoron
| ix.com/scan.php?page=news_item&px=NVIDIA-R...).
| salawat wrote:
| They're likely changing it because security researchers
| pwned FALCON.
|
| There is a way to leak the hash against which High
| Security mode FALCON compares the microcode for signature
| validation.
|
| So hopefully you'll forgive me if I maintain my
| skepticism over this being anything but Nvidia iterating
| to close a massive security defeat by redesigning their
| FALCON controller to mitigate the thorough pwning that's
| been achieved.
|
| I don't doubt there are other improvements, I just think
| the timing is pretty darn convenient, especially for
| being in the midst of a semiconductor shortage for going
| and doing a massive manufacturing change like that.
| zokier wrote:
| 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.
| jacooper wrote:
| > presumably works only with their own userspace drivers.
|
| 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...
| jacooper wrote:
| 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+)
| https://blogs.gnome.org/uraeus/2022/05/11/why-is-the-open-so...
| cosmiccatnap wrote:
| I don't normally curse on HN but I think I speak for all of us
| when I say
|
| Fucking finally.
| [deleted]
| zepearl wrote:
| Public post by nVidia: https://developer.nvidia.com/blog/nvidia-
| releases-open-sourc...
| tonnydourado wrote:
| Ten bucks Linus will curse at them in the near future.
| throwaway8486 wrote:
| May be but atleast he wont show the middle finger
| [deleted]
| ASalazarMX wrote:
| I did a double take because the title is almost clickbait for us
| desktop Linux users, and immediately wondered "what's the
| catch?". It's a significant catch, but also a significant step in
| the right direction.
| bombcar wrote:
| It sounds like this "GSP" lets them binary blob their "secret
| sauce" on the controller itself, so the rest of the driver can
| be open source now.
| madushan1000 wrote:
| Probably all their "enterprise" feature lockouts(vgpu etc..)
| are in the gigantic firmware that's loaded into GSP. But
| things that matter to desktop users probably aren't going to
| be locked out this way.
| exikyut wrote:
| I8, 8 ,8I
| `8b d8b d8'
| "8, ,8"8, ,8"
| Y8 8P Y8 8P ,adPPYba, 8b db d8
| `8b d8' `8b d8' a8" "8a `8b d88b d8'
| `8a a8' `8a a8' 8b d8 `8b d8'`8b d8'
| `8a8' `8a8' "8a, ,a8" `8bd8' `8bd8' ._.
| `8' `8' `"YbbdP"' YP YP `~'
| black_puppydog wrote:
| 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'm assuming here it's not because
| of LAPSUS as some speculate. This seems like it must have been in
| the making for quite a while.
| bcatanzaro wrote:
| I didn't work on this but I have watched it with interest for a
| very long time. It has been a strategic initiative in order to
| improve the GPU compute ecosystem. No one loves having a
| tainted kernel and everyone who uses a GPU with Linux (which is
| almost all data center GPUs) would prefer to have the kernel
| modules open source. It took a lot of work and planning to
| figure out how to do this over many teams for a very long time,
| and then an enormous amount of testing to prove the new drivers
| were fast enough to be deployed.
| exikyut wrote:
| 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'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
| bcatanzaro wrote:
| This functionality has been rolled out (shipping) for the
| past year. From the blog post: "This was made possible by
| the phased rollout of the GSP driver architecture over the
| past year, designed to make the transition easy for NVIDIA
| customers. https://download.nvidia.com/XFree86/Linux-x86_64
| /510.39.01/R..."
| e12e wrote:
| This is great. Anyone know how/if this will/does impact laptops
| with nvidia dGPU?
| dzogchen wrote:
| Wow, this is big for Linux & Nvidea isn't it?
| gchamonlive wrote:
| Does this mean we get a bit closer to having native, kernel-level
| Optimus drivers for Linux?
| snshn wrote:
| Nvidia... THANK YOU!
| teekert wrote:
| Nvidia module does not taint kernel anymore!
| ece wrote:
| 16xx, 20xx, 30xx, and some enterprise cards. Still great
| progress.
| Pr0ject217 wrote:
| lol!
| est31 wrote:
| For the uninitiated: If the linux kernel is asked to load a
| module with an incompatible license, it's called "tainted":
| https://www.kernel.org/doc/html/latest/admin-guide/tainted-k...
| nsajko wrote:
| > load a module with an incompatible license
|
| Loading any out-of-tree module taints the kernel, for example
| the vbox modules are GPL: https://archlinux.org/packages/comm
| unity/x86_64/virtualbox-h...
| teekert wrote:
| 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't think so)? Is it the succes of Steam
| (Deck)? Is is Proton? Deep Learning? Probably all of it...
| BeefySwain wrote:
| > 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?
| mc4ndr3 wrote:
| Will Linus revisit his rejection of Nvidia integration?
| geerlingguy wrote:
| With this announcement, I'm now interested in trying out some
| Nvidia graphics cards on the Pi again. Nouveau had some issues,
| and the official drivers had no source available, so I couldn't
| hack them to work.
|
| With the source available... it could be possible! Of course,
| CUDA support may never happen there, at least not using open
| source code.
| adolph wrote:
| <meta>-F geerl: not disappointed
|
| Thank you for the work you do, I'm going through your ssd on
| rpi4 today!
| remexre wrote:
| Which ones are connectable to it? And does this rely on the
| "replace the USB3 controller with a PCIe bridge" hardware mod?
| aftbit wrote:
| 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'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's name or look at
| links in his profile.
| jacooper wrote:
| Its a bit too early now isn't it ? The driver is still very
| alpha, and doesn't support most display stuff.
| geerlingguy wrote:
| 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/other stacks.
| malikNF wrote:
| https://github.com/geerlingguy
| DantesKite wrote:
| I wonder what impact this will have on the SteamDeck if any.
| jonny_eh wrote:
| The Steam Deck uses an AMD GPU, so it was probably the other
| way around. I'm betting this was partly done so nVidia GPUs can
| be used in similar devices going forward.
| ghishadow wrote:
| they are contributing to
| https://github.com/Plagman/gamescope/pull/454 which is SteamOS
| session compositing window manager. so maybe in future Steam
| Deck will Nvidia tech.
| kadoban wrote:
| Wow! I literally never thought I'd see the day.
|
| 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.
| hansihe wrote:
| 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.
| pluc wrote:
| The same could be said of a lot of Nvidia IP which was leaked a
| few months ago.
|
| But this is different, it's voluntary.
| amluto wrote:
| 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.
| mzs wrote:
| >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.
| tomxor wrote:
| Thanks for clearing that up, for a second I thought nVidia was
| finally Linux viable.
| [deleted]
| weinzierl wrote:
| I wonder if it is the result of the LAPSUS$ hack. This was their
| statement from early March:
|
| _" After evaluating our position and Nvidia's, we decided to add
| one more requirement._"
|
| _" We request that Nvidia commits to completely Open Source (an
| distribute under a FOSS License) ther GPU drivers for Windows,
| macOS and Linux, from now on and forever."_
|
| _" If this request is not met, on Friday we will release the
| complete Silicon, Graphics and Computer Chipset Files for all
| recent Nvidia GPUs."_
| messe wrote:
| I wonder if that means their userspace drivers will follow
| soon.
| ladyanita22 wrote:
| No way they're releasing CUDA or Nvidia RTX code. That'll
| stay closed source (and I respect that)
| anthk wrote:
| Well, the libre GNU world world will be able to use OpenCL
| with even more performance.
| bayindirh wrote:
| They may be limiting that stuff on the closed source
| parts or at the firmware level. Nvidia no way will allow
| full blown OpenCL/Vulkan performance and support on their
| cards.
| sylware wrote:
| Direct GPU assembly programing for even more performance,
| like with AMD GPUs.
|
| I guess the nintendo switch "may" benefit from GPU
| assembly programing... that said, AMD GPU isa
| documentation is top notch and I wonder if nvidia will
| follow up to there.
| etaioinshrdlu wrote:
| Incredible if extortion actually worked.
| bogwog wrote:
| 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.
| [deleted]
| Metacelsus wrote:
| >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.
| HidyBush wrote:
| I don't think so. Phoronix.com just over a year ago reported
| that a big GPU maker was going to open source their drivers. I
| can't find the link but I believe this thing has been in the
| making for a long while
|
| [edit] found it:
| https://www.phoronix.com/scan.php?page=news_item&px=Big-New-...
| xbar wrote:
| Definitely. There are no coincidences in Nvidia strategy.
| salawat wrote:
| This doesn't actually solve the major standing issue with
| Nvidia's drivers as far as I'm aware, because the biggest thorn
| has been the secretful FALCON units, and the code signing of
| firmware blobs that's kept projects like nouveau from being
| able to gain traction.
|
| Remember, it isn't enough that the kernel module is FOSS. The
| firmware is where the crux is.
| anthk wrote:
| Radeons have the same issue, tho.
| [deleted]
| kiechu wrote:
| https://youtu.be/_36yNWw_07g Linus expressing his deepest
| gratitude.
| yellowapple wrote:
| The Devil's putting on ice skates.
| etaioinshrdlu wrote:
| I am guessing the Nvidia is more okay with doing this because
| they have moved more functionality to the userspace components?
| 8organicbits wrote:
| 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.
|
| https://www.ibtimes.com/nvidia-geforce-graphics-card-virtual...
| iepathos wrote:
| Thank you nvidia, we've been waiting for this and you finally
| came through for us!
| jpe90 wrote:
| I didn't see anything for Pascal GPUs, are they left out?
| jabl wrote:
| Yes, Turing or newer is a hard requirement.
| jpe90 wrote:
| There is no god
| madushan1000 wrote:
| With the kernel driver open source + redistributeble firmware I
| guess the graphics APIs can be provided by mesa.
| SemanticStrengh wrote:
| 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??
|
| https://mesamatrix.net/
| madushan1000 wrote:
| I guess nobody bothered to add vulkan support due to almost
| unusable performance without reclocking. Hopefully some work
| will get started with this news!
| [deleted]
| SemanticStrengh wrote:
| reclocking.. You're reminding me of so many memories of
| years of a decade of reading phoronix nouveau news. (btw
| nouveau mean new in french)
| jacooper wrote:
| 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.
|
| https://blogs.gnome.org/uraeus/2022/05/11/why-is-the-open-so...
| feanaro wrote:
| I've never properly understood _why_ the closed source AMD
| driver still exists. Is it substantially different from the
| open source one? Does it offer anything not included in the
| open source one?
| outworlder wrote:
| OpenCL, for one.
|
| If you don't care about that, you can run pretty much
| anything else and performance is great.
| geerlingguy wrote:
| I think support for professional users.
| SXX wrote:
| 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
| sobkas wrote:
| > 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.
| the_duke wrote:
| I wonder if this has been in the works for years, or if this is a
| reaction to the recent Lapsus hack.
| ssl232 wrote:
| I'd be interested to know too. The hackers purportedly demanded
| release of the Nvidia drivers as open source:
|
| > The LAPSUS$ hacking group, which has taken credit for the
| breach, had an unusually populist demand: it stated that it
| wants Nvidia to open source its GPU drivers forever and remove
| its Ethereum cryptocurrency mining nerf from all Nvidia
| 30-series GPUs (such as newer models of the RTX 3080) rather
| than directly asking for cash. [1]
|
| [1] https://www.theverge.com/2022/3/4/22962217/nvidia-hack-
| lapsu...
| StillBored wrote:
| The datacenter focus here probably just means that $$$$ did the
| talking somewhere. AKA some large customer/former
| customer/potentially former customer said "open source or else"
| and they decided that having a couple people clean up, and push
| the special bits into the firmware/etc was a good way to solve
| the problem and keep $ALTERNATIVE at bay for the next
| generation or two.
| viksit wrote:
| 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] https://www.spinics.net/lists/xf-xpert/msg04601.html
| SemanticStrengh wrote:
| I thought they had open source CUDA kernels for a minute..
| samus wrote:
| Since the open sourced drivers are explicitly stated in TA to
| also help the Nouveau driver improve, the latter does not matter
| that much. That's what Mesa is here for.
___________________________________________________________________
(page generated 2022-05-11 23:00 UTC)