Announcement

Collapse
No announcement yet.

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

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

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

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    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

    Comment


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

      Comment


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

        Comment


        • #5
          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.

          Comment


          • #6
            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; 20 February 2012, 02:11 PM.

            Comment


            • #7
              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.

              Comment


              • #8
                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.

                Comment


                • #9
                  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

                  Comment


                  • #10
                    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.

                    Comment

                    Working...
                    X