Page 1 of 5 123 ... LastLast
Results 1 to 10 of 44

Thread: There's Hope For DMA-BUF With Non-GPL Drivers

  1. #1
    Join Date
    Jan 2007
    Posts
    14,361

    Default There's Hope For DMA-BUF With Non-GPL Drivers

    Phoronix: There's Hope For DMA-BUF With Non-GPL Drivers

    There's some resurrected hope for the kernel symbols of the DMA-BUF buffer sharing mechanism to be not restricted to only GPL drivers, which started off as a request by NVIDIA. This could lead to better NVIDIA Optimus support under Linux, among other benefits...

    http://www.phoronix.com/vr.php?view=MTA1OTU

  2. #2
    Join Date
    Dec 2007
    Location
    Edinburgh, Scotland
    Posts
    574

    Default

    I'm still not sure this is a good thing

    I foresee lots of fights over the years, NVIDIA are probably better off incorporating an Intel driver into their code like AMD did with their binary driver

    It sets a bad example and it won't encourage SOC manufacturers to create open drivers

  3. #3
    Join Date
    Jan 2011
    Posts
    98

    Default

    Release open drivers already, Intel and (mostly) AMD have done that, and no rogue manufacturer has been seen feasting with their super-secret IP.

  4. #4
    Join Date
    May 2008
    Posts
    73

    Default

    Let's bargain: you want us to export these symbols? Well we want KMS

  5. #5
    Join Date
    Oct 2009
    Posts
    845

    Default

    The upstream open-source Linux kernel developers weren't really in favor of this change to allow non-GPL drivers access to DMA-BUF.
    Are there any upstream closed-source Linux kernel developers? This weird statement and the highlighting of Rob Clark's post as positive implies that there's something negative with the kernel developers not being interested in helping proprietary drivers. I think it's exactly the opposite, there would be far fewer open source drivers support directly by the kernel if it wasn't a chore for companies to maintain them as binary modules. NVidia is the big holdout these days, which thanks to the amazing work by the Nouveau devs is less of a nuisance with each release.

    NVidia will never care one lick for Linux as an ecosystem, they only support Linux with drivers because Linux is a powerhouse in the 3D/SFX market. Judging from the follow-up posts in that mailing lists the other kernel devs chiming in was anything but entusiastic about that idea and I concur.

  6. #6
    Join Date
    Feb 2008
    Location
    Santiago, Chile
    Posts
    236

    Default

    If I were a kernel developer answering this question of whether NVIDIA should be allowed to link its driver to DMA-BUF, based in history and on legal grounds, I'd say:

    OVER. MY. DEAD. CORPSE.

    The fact that NVIDIA fought a pathetic fight to keep their nForce code closed and to support a binary blob for something as basic as a NIC (an already lost battle thanks to the guys behind forcedeth) doesn't help.
    Last edited by Alejandro Nova; 02-20-2012 at 01:11 PM.

  7. #7

    Default

    If this proposal will be approved it will not be a win for linux users. I would say it will be a 50% win 50% loose. Ok users of binary drivers have something more (if you do agree to nvidia, you agree with all binary blobs to use dma-buf of course), but free software loose on of its key point, to not say this is a quite clear violation of the GPL license as I read what Alan Cox says. Rob Clark is right, if ARM SoC can use DMA-BUF with closed binary blobs, there is no reason to stop nvidia. But i ask myself why DMA-BUF work has began given no free (as in freedom) ARM GPU driver exists. Ok maybe there will be, but given one of the DMA-BUF creators works for one of the most known ARM chip maker.... we can understand why binary blobs can use DMA-BUF. And there is nothing wrong with it of course, if the authors are ok with that. But then don't call it GPL software please.

    On the other hand untill devices don't work as expected is a loose anyway for users...... drivers must be free (and working!) for a real win.

  8. #8
    Join Date
    Jul 2007
    Posts
    176

    Default

    Quote Originally Posted by FireBurn View Post
    I'm still not sure this is a good thing

    I foresee lots of fights over the years, NVIDIA are probably better off incorporating an Intel driver into their code like AMD did with their binary driver

    It sets a bad example and it won't encourage SOC manufacturers to create open drivers
    Nvidia should have indeed incorporated an Intel driver and supported hybrid graphics, as most mid-range laptops with Nvidia graphics are Optimus-based. However, I am not really a big fan of this setup - there is a slight but noticeable lag on my laptop with hybrid Intel-ATI graphics, so I wonder if there is a faster setup. I haven't checked how it performs on Windows though - perhaps these muxless hybrid graphics systems are inherently laggy.

    I also think the dma-buf should be opened up to closed-source drivers -- as I understand, the debate is mostly political than technical.

  9. #9
    Join Date
    Dec 2007
    Location
    Edinburgh, Scotland
    Posts
    574

    Default

    Quote Originally Posted by hdas View Post
    I also think the dma-buf should be opened up to closed-source drivers -- as I understand, the debate is mostly political than technical.
    There's legal issues as well - most due to the loose definition of a derived work

  10. #10
    Join Date
    Oct 2008
    Posts
    3,036

    Default

    Quote Originally Posted by hdas View Post
    I also think the dma-buf should be opened up to closed-source drivers -- as I understand, the debate is mostly political than technical.
    I think it rests heavily on how unique this API is to linux.

    If it's unique, then anything using it would be based on the GPL work and would legally HAVE TO BE GPL as well.

    If you can argue that the API is general, and present on other operating systems, then I think you have a strong argument that it should be marked available for the binary drivers.

Posting Permissions

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