Announcement

Collapse
No announcement yet.

AMD Graphics Driver Surpassing 4 Million Lines Of Code In Linux 5.19, NVIDIA Opens Up At 1 Million

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    If the policy "no opensource userland = no mainlining for kernel driver" is still valid, that kernel driver won't ever be merged into mainline.
    And the userland part won't be opensourced, as stated by NVIDIA FAQs, I guess this is just some help for nouveau guys.

    Comment


    • #12
      Originally posted by blackshard View Post
      If the policy "no opensource userland = no mainlining for kernel driver" is still valid, that kernel driver won't ever be merged into mainline.
      And the userland part won't be opensourced, as stated by NVIDIA FAQs, I guess this is just some help for nouveau guys.
      From my communication with NVIDIA and given Red Hat's involvement,. Nouveau Mesa will likely gain support for using the new kernel driver and that addresses the upstreaming kernel driver requirements as long as the Nouveau Mesa code makes use of all the exposed interfaces.
      Michael Larabel
      https://www.michaellarabel.com/

      Comment


      • #13
        Originally posted by blackshard View Post
        If the policy "no opensource userland = no mainlining for kernel driver" is still valid, that kernel driver won't ever be merged into mainline.
        And the userland part won't be opensourced, as stated by NVIDIA FAQs, I guess this is just some help for nouveau guys.
        It is great even in current state - just to have the ability to patch kernel side driver with some useful stuff, like ReBar on unsupported systems and build it with march=native and not use linked prebuilt blob.

        Comment


        • #14
          Originally posted by Michael View Post

          From my communication with NVIDIA and given Red Hat's involvement,. Nouveau Mesa will likely gain support for using the new kernel driver and that addresses the upstreaming kernel driver requirements as long as the Nouveau Mesa code makes use of all the exposed interfaces.
          It seems unlikely to ever go upstream while they are still just doing 1 git commit per release with everything dumped together. So I think there's still a lot of workflow issues that need to be done on NVidia's side before it makes sense to even begin discussing upstreaming.

          Comment


          • #15
            Shame that there's no actual driver code in any of those 1M lines. It seems it's all been shoved down into 30+ MB of firmware.

            Comment


            • #16
              Originally posted by Developer12 View Post
              Shame that there's no actual driver code in any of those 1M lines. It seems it's all been shoved down into 30+ MB of firmware.
              It's certainly in their right to split functionality between the device (firmware) and the host (driver) as they see fit. Open-sourcing the host side resolves most practical concerns (maintainability and security) regardless of the split.
              Last edited by intelfx; 12 May 2022, 02:42 PM.

              Comment


              • #17
                Originally posted by V1tol View Post

                It is great even in current state - just to have the ability to patch kernel side driver with some useful stuff, like ReBar on unsupported systems and build it with march=native and not use linked prebuilt blob.
                ReBar on unsupported systems? Can you really rebar non Ampere gpus?

                Comment


                • #18
                  Originally posted by intelfx View Post
                  It's certainly in their right to split functionality between the device (firmware) and the host (driver) as they see fit. Open-sourcing the host side resolves most practical concerns (maintainability and security) regardless of the split.
                  If it's really 30MB of code, I doubt it's all secure. It might make it easier to fuzz and hence find issues in, though?

                  Comment


                  • #19
                    Originally posted by intelfx View Post

                    It's certainly in their right to split functionality between the device (firmware) and the host (driver) as they see fit. Open-sourcing the host side resolves most practical concerns (maintainability and security) regardless of the split.
                    Except it doesn't because its exactly the same situation as before... a binary blob is tainting your system, sure it isn't tainting the kernel directly now but that's moot as PCIe devices have unfettered access to the PCIe bus. So in effect you still have 30MB of unknown code running in your system.... this is a bit less of a concern for sane firmware but a 30MB blob is far and away from that.

                    Comment


                    • #20
                      Originally posted by er888kh View Post
                      Oh, that's a good start! At least those with Nvidia cards can start testing, although personally I'll be sticking with AMD until at least next year.

                      Originally posted by Michael View Post

                      It would be very surprising if it's mainlined even this year at all.... The API/ABI isn't yet stable, no Mesa clients using the kernel driver yet, etc.... Lots of work ahead. At least a few kernel cycles before it would likely be stable enough for mainline.
                      That's what I was expecting considering how long it took AMD's stuff to get into mainline. I'm in no rush to buy Nvidia GPUs anyway but good to know at least the kernel side will be better supported if I ever do.

                      Comment

                      Working...
                      X