Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 31

Thread: NVIDIA's PRIME Helpers Are Ready For Linux 3.9

  1. #11
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,934

    Default

    Quote 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

  2. #12
    Join Date
    Nov 2008
    Location
    Old Europe
    Posts
    936

    Default

    Quote 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?

  3. #13
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,665

    Default

    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

  4. #14
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,934

    Default

    Quote 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

  5. #15
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,665

    Default

    Quote 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.

  6. #16
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,934

    Default

    Quote 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

  7. #17
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,801

    Default

    Quote 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?

  8. #18
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,665

    Default

    Quote 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.

  9. #19
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,934

    Default

    Quote 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"

  10. #20
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,665

    Default

    Quote 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...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •