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

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

  • #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; 02-20-2012, 01: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


                    • #11
                      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.
                      Not quite. It's not technical, in the sense that it would be difficult to expose those interfaces. But it's technical in the sense that supporting binary drivers is a pain in the ass. For the most part, that's the kernel developers main issue around binary modules - it's less about the politics and ethics of closed source, and more about an unwillingness to deal with invisible code.

                      Comment


                      • #12
                        But having it as GPL wont "force" anyone to mark their software as GPL (or other FOSS licence) ... I pretty much share the PoV in this article → http://www.theregister.co.uk/2011/05...rs_and_takers/
                        If that codepath is GPL, nVIDIA won't use it, and won't open up their drivers...end of the story : No Optimus Support

                        They support Linux because it's in their interests, not because "it's a good cause" ... and, unfortunately I don't see Optimus with any kind of application outside the consumer market.
                        Unfortunately nVIDIA is not the kind of company that likes to play "open"

                        So, that's when, as customers (of whatever GPUs) we have to be vocal about the importance of FOSS drivers for us.

                        Regards.

                        Comment


                        • #13
                          I guess we could say that this would be nice+convenient for the short term, but most likely damaging for the long term. So thanks, but no thanks. We can live perfectly well with the blob as-is for a few more years until the OSS drivers will be able to handle this (assuming they will...).

                          Comment


                          • #14
                            Originally posted by peppepz View Post
                            Release open drivers already, Intel and (mostly) AMD have done that, and no rogue manufacturer has been seen feasting with their super-secret IP.
                            They haven't released any super-secret IP.

                            Most of the "magic" in the AMD/NVIDIA proprietary drivers is nowhere to be seen in the Open ones, particularly their shader compilers, command queue schedulers, video decoding, and so on.

                            Comment


                            • #15
                              I have to laugh at all the people here who feel like making comments without even reading the LKML thread. If they did, then they would know that the issue is not that the kernel should be enforcing the GPL on external modules, but the contrary; it should not. The current behavior is a bug. External APIs have to be flagged as such. That's Linux kernel policy and it has been there for ages. It's vital that Linux can be used by proprietary vendors and that you can run proprietary software. But the DMA-BUF API, even though it is a driver interface, has not been flagged as an external interface, even though it should have been.

                              But if you guys would even care to spend 3 minutes to read the LKML message, then you would have known this. Instead, you chose to make up an issue that doesn't even exist: Linux infecting all software that runs in it with its own license, trying to prohibit people who disagree with it from making their own choices. Linux clearly doesn't do that, never did and never intended to. That's Microsoft's business model, not Linux's.
                              Last edited by RealNC; 02-20-2012, 06:07 PM.

                              Comment

                              Working...
                              X