Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Open Source

Nvidia Will Fully Transition To Open-Source GPU Kernel Modules With R560 Drivers 50

Posted by BeauHD from the what-to-expect dept.
Nvidia is ready to fully transition to open-source Linux GPU kernel drivers, starting with the R555 series and planning a complete shift with the R560 series. The open-source kernel modules will only be available for select newer GPUs, while older architectures like Maxwell, Pascal, and Volta must continue using proprietary drivers. TechSpot reports: According to Nvidia, the open-source GPU kernel modules have helped deliver "equivalent or better" application performance compared to its proprietary kernels. The company has also added new features like Heterogeneous Memory Management (HMM) support, confidential computing, and the coherent memory architectures of the Grace platform to its open-source kernels. [...] For compatible GPUs, the default version of the driver installed by all methods is switching from proprietary to open-source. However, users will have the ability to manually select the closed-source modules if they are still available for their platform.

Unfortunately, the open-source kernel modules are not available for GPUs from the older Maxwell, Pascal, and Volta architectures, meaning people still running a GTX 980 or GTX 1080 will have to continue using Nvidia's proprietary drivers. For mixed deployments with older and newer GPUs in the same system, Nvidia recommends continuing to use the proprietary driver for full compatibility. "Nvidia has moved most of its proprietary functions into a proprietary, closed-source firmware blob," adds Ars Technica's Kevin Purdy. "The parts of Nvidia's GPUs that interact with the broader Linux system are open, but the user-space drivers and firmware are none of your or the OSS community's business."
This discussion has been archived. No new comments can be posted.

Nvidia Will Fully Transition To Open-Source GPU Kernel Modules With R560 Drivers More

Nvidia Will Fully Transition To Open-Source GPU Kernel Modules With R560 Drivers

Comments Filter:

  • Whoopee! (Score:5, Insightful)

    by divide overflow ( 599608 ) on Thursday July 18, 2024 @05:27PM (#64636077)

    "Nvidia has moved most of its proprietary functions into a proprietary, closed-source firmware blob," adds Ars Technica's Kevin Purdy. "The parts of Nvidia's GPUs that interact with the broader Linux system are open, but the user-space drivers and firmware are none of your or the OSS community's business."

    So now, instead of the whole driver being a big binary blob, only a portion of the driver is a big, binary blob...right?
    I wouldn't call this a victory for open source.

    • Re: Whoopee! (Score:4, Insightful)

      by samwichse ( 1056268 ) on Thursday July 18, 2024 @09:58PM (#64636513)

      It should make the drivers less of a PITA to install/update, which is a big win, IMO. GPL and MIT dual license, so they'll be right in your distros repos and I assume the binary blobs can be distributed like all the other binary firmware blobs already are, and as seamlessly.

      Maybe I won't just go AMD by default for my next build. Let's see how it works out.

    • Re: (Score:2, Informative)

      by tlhIngan ( 30335 )

      So now, instead of the whole driver being a big binary blob, only a portion of the driver is a big, binary blob...right?
      I wouldn't call this a victory for open source.

      nVidia's drivers have always been partly binary blob.

      All they did is realize they can push all the binary blobs to userspace and thus make the kernel part a thin access layer.

      It wouldn't really affect performance since on other platforms (e.g., Windows), that's already what happesn. You have basically a three layer driver. The top layer interf

      • Will the binary blob ship together with the Linux source or distro packages? Or do users still have to install them from a third party, which was part of the complication behind closed-source drivers?

      • nVidia's drivers have always been partly binary blob.

        Different binary blob.
        The binary kernel blob is going away.
        The binary blob that will continue is the one that runs on the card, which is already there even today with the kernel binary blob.
        The kernel driver isn't a thin access layer. It's a full DRM/KMS/FB implementation.

        All nVidia did was move the bits that should've been in userspace to userspace (i.e., all the binary blob bits)

        No. So much no.

    • I wouldn't call this a victory for open source.

      I would.
      The primary PITA with the closed-source drivers, is that the community has not been able to adapt them to changing user-space pipeline changes, like the transition to Wayland. So while Wayland has been the default for AMD GPUs for literally years now, NV has had to stay using Xorg.

      The fact that the stuff that drives the hardware function blocks is now separated from the driver is a good thing, and frankly, there isn't a huge amount of value for Joe Average in those components being open source an

  • So if Nvidia goes open source on the drivers, I guess Torvalds may change his opinion on Nvidia?

    • Probably, if that was what was actually happening here, which it's not. But it does sound like they're gonna open source a bit more of it, so maybe it'll at least help a little bit with existing platform integration shortcomings.

      • The code to open channels and talk to the GPU gets open sourced. The actual firmware on the GPU and the user space runtime are still proprietary.

      • Re: (Score:2, Informative)

        by Trongy ( 64652 )

        It sounds like you've misunderstood. Nvidia released the open source kernel module two years ago, while still supporting their propriety kernel module. What's new in this announcement is that they are dropping support for the propriety kernel module on hardware that is supported by the open source kernel module. There's nothing new that will be open sourced.

    • ...I guess Torvalds may change his opinion on Nvidia?

      Maybe Linus' "Fuck You" finger will only go up 3/4ths of the way now, since NVidia is only opening a small part of their driver.

    • Re: (Score:2)

      by brad0 ( 6833410 )
      No, NVidia has a long way to go to show they're willing to play well in the open source ecosystem.

      • No, NVidia has a long way to go to show they're willing to play well in the open source ecosystem.

        For most of the actual things one would use an Nvidia graphics card for, the closed-source, proprietary driver is fine. I've used it regularly under Linux (Mint and VoidLinux) and for many, many years (and currently) under FreeBSD. Solid as a rock, easy to install from packages typically, no problemo.

        I am not 100% sure where the degree of hate for Nvidia comes from when the Linux kernel is already chock full of binary blobs for network cards, wifi chipsets and other hardware, hell even CPU microcode updates

  • If it makes the drivers less finicky to install (Score:4, Informative)

    by 93 Escort Wagon ( 326346 ) on Thursday July 18, 2024 @05:52PM (#64636139)

    I'm all for it.

    The packaged-based installers never seem to get the driver installed and functional on our hardware, so I haven't had success automating the process. I have to sit down at every box and execute the Nvidia / CUDA ".run" files, manually disable Nouveau, etc. etc. to be successful.

  • How much are they open-sourcing, and how much are they moving into that proprietary, closed-source firmware blob?

    If the answer is "most of the driver is still closed" then I think "Nvidia Will Fully Transition to Open-Source GPU Kernel Modules" is just lying to us.

    • Re: (Score:2)

      by Kaenneth ( 82978 )

      "Kernel Modules" is pretty clear.

      • Kernel modules that all they do is load a binary blob

        • The current kernel module just loads a binary blob that runs in kernel space.
          That is what is going away.
          Instead, you will have a full open source driver that interacts with the hardware.
          Newer NV cards have certain functionality (like scheduling) running on a little CPU on the card. The firmware for that will continue to be a blob.
          100% of the driver will be open source.
          The firmware for the card is not.

          This isn't even remotely strange in the hardware world.
          AMD's firmware binaries are also non-free bin

      • It is, but it doesn't say anything at all about how much of their old proprietary, closed-source kernel modules will end up in their new open-sourced kernel modules and how much will end up in the proprietary, closed-source firmware blob, which was the question I was asking.

  • I went all-AMD because of their bluster about being open source champions but when CUDA came along and even I couldn't get the ROCm drivers to build or install from rpm, we bought nVidia just to have something that works.

    I mean, I am quite subborn and once ported povray to 64-bit just to get it to run on an Alpha, but a full day in and having to do it repeatedly for future releases was like, "nah, cut the losses".

    The APU's are great for small machines, though!

    Anybody in a security-first environment will hav

  • My laptop crashes a lot in suspend resume due to nvidia. The only reason I bother with nvidia is cuda, but that is very unstable, too. I often have to uninstall and load the module again. It might help that the integration into Linux becomes open source and maybe even upstreamed.
    • It's been a decade since I had a suspend issue with my laptop.
      Currently, RTX 2060, 10th gen i9, ubuntu-latest.
      Also zero problems with compute, at least in the capacity that I've used it there, which is JTR and Stable Diffusion.

      I think maybe the problems you're having aren't solely the fault of your NV.

  • O RLY? (Score:3)

    by Gravis Zero ( 934156 ) on Thursday July 18, 2024 @08:29PM (#64636427)

    but the user-space drivers and firmware are none of your or the OSS community's business."

    So long as there are zero bugs in the user-space drivers and firmware then I'm OK with this. If this were true then the firmware would be stored on ROM and the firmware could not be replaced which of course is obviously not happening.

    So long as it can be modified and it executes code then it's 100% my and the OSS community's business.

    • So long as it can be modified and it executes code then it's 100% my and the OSS community's business.

      Of course.

      Unfortunately, that means you can't use half the shit on your computer.
      NIC? nope.
      Wifi? nope.
      CPU? nope.
      GPU? nope.

      This is an improvement from what was, to basically the status quo for nearly all hardware on a PC.

      • Unfortunately, that means you can't use half the shit on your computer.

        My point was that it's the concern of the OSS community in response to "it's none of your business".

        This is an improvement from what was,

        That really depends on your timeline because in the 90s none of these had replaceable firmware. Only in the later half of the 90s did CPUs get loadable microcode as a result of the Pentium FDIV bug. By all accounts, all hardware has gotten much worse as a result companies being able to fix flaws in post-production via the internet.

        • My point was that it's the concern of the OSS community in response to "it's none of your business"

          Oh- I agree, that is a seriously fucking inflammatory remark. But it comes from the author- not the vendor in question.
          In my experience working with embedded hardware, "it's none of your business" is never really the attitude they have about this kind of stuff. Often, they wish it was your business. But there are real-world concerns over opening proprietary code.
          That isn't to justify doing it, or saying it's impossible or something- just that thinking that there's only one interest that matters- your own,

          • More importantly, are the little embedded CPUs running in your favorite AMD and Intel

            Yeah, the AMD PSP and Intel ME. IME is absolutely as bad as everyone predicted back in the day. However, I'm pretty sure the PSP is much newer by comparison and thus far is only on the Zen microarchitecture.

            • Ya, PSP is Zen only (circa 2013).

              These things (IME, PSP) are, in my opinion, the largest security threat there is for the PC architecture, simply by virtue of the 100% transparent way they can act. The OS can never know what it did. It can transparently intercept memory accesses. The firmware blob on your GPU pales in comparison as far as concern goes, IMHO.

              While some of the functions they provides by doing that transparent interception- emulating hardware- are neat and useful- the completely powerlessn

              • Ya, PSP is Zen only (circa 2013).

                Perhaps but I think Zen only become a big seller in 2017. I guess my system is "ancient" because my workstation still doesn't have it.

                These things (IME, PSP) are, in my opinion, the largest security threat there is for the PC architecture

                Agreed. However, it's possible to disable PSP in the UEFI settings on some motherboards. I don't know if there are settings to disable IME but I do know people have found ways to cause it to halt.

                The firmware blob on your GPU pales in comparison as far as concern goes

                Yes and no. Yes in that GPU hardware and firmwares are far more varied in nature making them a harder target. However, no in that PCIe devices are able to directly access RAM without [superuser.com]

                • Agreed. However, it's possible to disable PSP in the UEFI settings on some motherboards. I don't know if there are settings to disable IME but I do know people have found ways to cause it to halt.

                  I'm not 100% sure what "disable" it really means. Would be interesting to find out.
                  The CPU cannot boot without the PSP. The PSP boots up and negotiates the CPU startup with the mainboard EC. Dead PSP literally equals bricked CPU.
                  Maybe they mean they shut it off once it's done bootstrapping the CPU.

                  Yes and no. Yes in that GPU hardware and firmwares are far more varied in nature making them a harder target. However, no in that PCIe devices are able to directly access RAM without interfacing with the CPU [superuser.com] and can operate entirely independently of CPUs. Additionally, the attack surface of GPUs is much larger since firmwares are tens or even hundreds of megabytes. I certain that intelligence agencies, especially the NSA (which puts a heavy emphasis on going undetected), have some very powerful tools targeting many different GPUs that are kept in reserve for the most important assignments.

                  PCIe devices are gated by an IOMMU- i.e., they are by default untrusted. It's true that they have DMA, but only once and where the CPU alllows it. Your CPU cannot be similarly gated.

  • None of your business (Score:5, Insightful)

    by Uldis Segliņš ( 4468089 ) on Thursday July 18, 2024 @09:48PM (#64636501)
    "but the user-space drivers and firmware are none of your or the OSS community's business" What an insult. And this is just another clickbait. I will continue using competitors GPUs. The finger must stay up.

  • no big deal (Score:3)

    by nicubunu ( 242346 ) on Friday July 19, 2024 @12:58AM (#64636709) Homepage

    If you ask me, I see no much improvement from going to a proprietary driver to a proprietary blob.

  • Not enough (Score:1)

    by Anonymous Coward

    Still has proprietary userspace.

    Nvidia is still not an option. They may be closer to being taken seriously, but they aren't there yet.

    To see drivers done right, see Intel and AMD.

  • They make it sound like there still are hidden parts, like firmware blobs. Didn't think those were allowed in the Linux kernel proper (like for wifi drivers, which made wifi on Linux annoying apparently).

    Either way, there is still hidden/magic code places. Sounds like they're just moving it into other places at best (from kernel to user mode for instance, which can have it's own issues... transitioning between the two has a cost as Microsoft realized way back when during the NT days).

Slashdot Top Deals

Never test for an error condition you don't know how to handle. -- Steinbach

Close