Announcement

Collapse
No announcement yet.

NVIDIA's PRIME Helpers Are Ready For Linux 3.9

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

  • #11
    Originally posted by johnc View Post
    How does this help them accomplish Optimus?

    I thought it was GPL issues that were the primary stumbling block.
    They are, the PRIME helpers introduces non-GPL interfaces for them to use instead of the standard DMA_BUF ones this way they arent directly touching GPL code and have a non-gpl middle layer between the driver and dma_buf
    All opinions are my own not those of my employer if you know who they are.

    Comment


    • #12
      Originally posted by Ericg View Post
      They are, the PRIME helpers introduces non-GPL interfaces for them to use instead of the standard DMA_BUF ones this way they arent directly touching GPL code and have a non-gpl middle layer between the driver and dma_buf
      Non-GPL code included to the vanilla Linux sources?
      How would that work?

      I think you mean it does not rely on Linux code that requires EXPORT_SYMBOL_GPL?

      Comment


      • #13
        Yea, I don't get it either. Unless it adds a new syscall, how can that help?

        This paragraph from the article, when trimmed to be proper, explains the original issue pretty well:
        NVIDIA can't directly utilize the Linux kernel's DMA_BUF buffer sharing mechanism -- a zero-copy way to share buffers between different kernel drivers whether it be DRM or other sub-systems -- due to GPL-only kernel

        Comment


        • #14
          Originally posted by entropy View Post
          Non-GPL code included to the vanilla Linux sources?
          How would that work?

          I think you mean it does not rely on Linux code that requires EXPORT_SYMBOL_GPL?
          2 Points...

          1) The majority of the code is under the GPL, yes. But considering Linux does not require copyright assignment, I'm pretty sure you can include any code that is under any license that is GPL compatible.

          2) Also yes, the new code would not use EXPORT_SYMBOL_GPL and would instead declare EXPORT_SYMBOL
          All opinions are my own not those of my employer if you know who they are.

          Comment


          • #15
            Originally posted by Ericg View Post
            2) Also yes, the new code would not use EXPORT_SYMBOL_GPL and would instead declare EXPORT_SYMBOL
            Which makes zero difference, as the kernel as a whole is GPL.

            Comment


            • #16
              Originally posted by GreatEmerald View Post
              Which makes zero difference, as the kernel as a whole is GPL.
              It matters for the shim layers. The shim layers have to be open source to meet the requirements of the GPL, but the pieces of software that interact with shim layers can then be closed source since there's a middle-man. The PRIME helper's are such a shim layer. Remember, the kernel isn't under a by-the-book GPLv2. Its GPLv2 with exceptions that supersede the GPLv2
              All opinions are my own not those of my employer if you know who they are.

              Comment


              • #17
                Originally posted by GreatEmerald View Post
                Which makes zero difference, as the kernel as a whole is GPL.
                Then why are you able to run non-GPL software on your Linux box?

                Comment


                • #18
                  Originally posted by Ericg View Post
                  It matters for the shim layers. The shim layers have to be open source to meet the requirements of the GPL, but the pieces of software that interact with shim layers can then be closed source since there's a middle-man. The PRIME helper's are such a shim layer. Remember, the kernel isn't under a by-the-book GPLv2. Its GPLv2 with exceptions that supersede the GPLv2
                  Yes, that's true, but then the layer must be non-GPL, and so it can't be a part of the kernel. So I can't see what the patches here achieve. GPL-compliant software can already use DMA-BUF without issues.

                  Comment


                  • #19
                    Originally posted by GreatEmerald View Post
                    Yes, that's true, but then the layer must be non-GPL, and so it can't be a part of the kernel. So I can't see what the patches here achieve. GPL-compliant software can already use DMA-BUF without issues.
                    This is about allowing the closed source drivers to interact with shared buffers in order to achieve Optimus (Nvidia) or Enduro (AMD). You can have non-GPL code in the kernel, thats not an issue. Thats why BSD licensed code can be incorporated into the kernel. Its traditional though to put everything under the GPL, but for some things--by design-- that doesnt work like these shim layers. So the shim layers themselves follow the BSD licensing rules or whatever license they are under.

                    Thats why Linus said "The kernel will always be GPLv2" He wasn't making a promise, he was stating a fact. Thanks to the fact that copyright assignment isnt forced, in order to change the license of the kernel as a whole The Linux Foundation would have to get the "Ok." From every single person who has ever committed one piece of code to the kernel and the code they didnt get an "Ok" for would have to be rewritten by someone who was giving their "Ok"
                    All opinions are my own not those of my employer if you know who they are.

                    Comment


                    • #20
                      Originally posted by Ericg View Post
                      This is about allowing the closed source drivers to interact with shared buffers in order to achieve Optimus (Nvidia) or Enduro (AMD). You can have non-GPL code in the kernel, thats not an issue. Thats why BSD licensed code can be incorporated into the kernel. Its traditional though to put everything under the GPL, but for some things--by design-- that doesnt work like these shim layers. So the shim layers themselves follow the BSD licensing rules or whatever license they are under.
                      Huh, really? Individual files can override the global license? Then what's the point of having a global license to begin with? And what does "relicensing the kernel" even mean in that case? After all, if a code file is under BSD, and people want to relicense the kernel to BSD, then it's not really relicensing for that particular code file...

                      Comment

                      Working...
                      X