Announcement

Collapse
No announcement yet.

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

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

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

            Comment


            • #16
              Originally posted by elanthis View Post
              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.
              And what magic did they have in the register layouts of their ethernet chips, that prevented them from releasing an open driver even for those? They could at least release datasheets, even deprived of the video decoding interfaces in the case of graphics cards. Their competitors, if that's their concern, can already obtain that information by reverse engineering their Windows drivers.

              Intel's drivers seem to work under Linux pretty much as well as they do under Windows, so they at least can manage to achieve acceptable results even without any special technique that supposedly they woudln't want to use in the open. I hope that in the future, either their upcoming hardware or AMD's open source drivers will raise the bar for open source graphics stacks, as Linux did for open source operating systems. Then Nvidia will feel it more "natural" to join the others.

              Comment


              • #17
                Originally posted by Alejandro Nova View Post
                OVER. MY. DEAD. CORPSE.
                I'd be freaking out if a corpse weren't dead

                Comment


                • #18
                  Speaking from an end-user (ie, non-developer) POV, i'm quite conflicted about the possibility of such a move.

                  On one hand, it does bring Linux hardware support up an additional notch now since hybrid graphics switching will finally be supported on desktop / notebook Linux, and in this case, NVIDIA itself is offering to provide Optimus support for Linux as long as this little issue about DMA-BUF is resolved by removing the restriction to export GPL symbols only. At least, it is much better than NIVIDA's previous behavior of completly shutting the door on Linux over optimus when it was first introduced in Windows 7 notebooks. And considering how Linus Torvalds once said that he considers the choice for any user to use any tool he / she desires. regardless of it being open or proprietary, as almost sacred, we have no say about what drivers a user should use, and they should be free to adopt any driver that bests suits their needs.

                  Thing is, by doing so, are we sending a signal that it is 'ok' to use binary drivers? Im not going to argue about the pros and cons of both open and closed drivers, but binary drivers are known to break whenever a distro rolls out a kernel update (eg: 2.6.27-20 to 2.6.27-30). And when end users find themselves faced with a blank screen and no X upon doing such an update, what is the first thing they do? Scream about how Linux sucks with updates, remove it and go back to Windows, and Linux gets a bad name for no reason. Also, there is the real possibility that lesser hardware companies will be inclined to release open drivers now that one key restriction is removed.

                  I'd vote for an interim solution in which the 'GPL symbols only' on DMA-BUF is allowed to be removed for a period of time for NVIDIA and only NVIDIA, and whether this restriction stays removed or not will depend entirely on NVIDIA's wilingness to play nice with our needs. As one user has said earlier, we can barter the restriction in exchange for KMS support or co-operation for other technologies, failing which the restriction will be reimplemented.

                  And anyway, it would appear that the Bumblebee + Nouveau support is moving along at quite a reasonable pace; sure you don't get the full performance of what the card is capable of doing, but at least there is rudimentary support for switchable graphics.

                  Comment


                  • #19
                    Thing is, by doing so, are we sending a signal that it is 'ok' to use binary drivers? Im not going to argue about the pros and cons of both open and closed drivers, but binary drivers are known to break whenever a distro rolls out a kernel update (eg: 2.6.27-20 to 2.6.27-30). And when end users find themselves faced with a blank screen and no X upon doing such an update, what is the first thing they do? Scream about how Linux sucks with updates, remove it and go back to Windows, and Linux gets a bad name for no reason. Also, there is the real possibility that lesser hardware companies will be inclined to release open drivers now that one key restriction is removed.
                    Demand some sort of stable KBI if that's your concern ...
                    Don't blame on others the lack of a proper and stable KBI. In FreeBSD I pretty much never had to recompile a driver in all revisions of code (only once, when capabilites were added in 9-CURRENT), in linux I had to recompile from one version to another.
                    The same applied to OpenSolaris/IllumOS

                    I'd vote for an interim solution in which the 'GPL symbols only' on DMA-BUF is allowed to be removed for a period of time for NVIDIA and only NVIDIA, and whether this restriction stays removed or not will depend entirely on NVIDIA's wilingness to play nice with our needs. As one user has said earlier, we can barter the restriction in exchange for KMS support or co-operation for other technologies, failing which the restriction will be reimplemented.
                    You write like we had something they need with dma-buf, you're wrong ... we need something they have, and it's hardware support.
                    this part of the post is completely different from " it is much better than NIVIDA's previous behavior of completly shutting the door on Linux over optimus"
                    remember, when we talk about privative software, it's their interest ... mark dma-buf as GPL, and they are shutting the door again.

                    I pretty much agree with the rest of your post.

                    i vote to make the linux kernel ---> AGPLv3+ to fight software patents and companies like GOOGLE!

                    they also should chance the lizence of X and MESA into AGPLv3!

                    because nvidia+amd just hurt open-source and free software with there closed source hardware drivers!

                    the Free world really should arming up against this shit!
                    And all the GNU software, including the libc, switched to GPL instead of licenses that allow linking from privative software.
                    Then all the free/open source software ecosystem will break.

                    Because right now those companies are doing HARD investments (maybe they aren't doing the "full thing" but we have pretty decent collaboration from companies ) in evolving linux.
                    Don't forget what company implemented what and where we would be without that.

                    Regards.

                    Comment


                    • #20
                      Proprietary drivers has always come across as management idiocy to me:

                      programmer: we could release these specs or even open source our proprietary driver as there's no ..

                      management: no! this is our intellectual property and it will be kept under lock and key.

                      programmer: but really, there's no secret sauce in th....

                      management: no!


                      ...


                      programmer: as we can see from this slideshow I made so that idiots can understand it, it's costing us alot of resources and thus money to maintain our own out of tree proprietary driver, and it's also preventing us from utilizing useful services provided by the targeted system.

                      management: oh, yes, I see this seems to cost us alot of time and money. you said there were nothing in our proprietary code which is a trade secret?

                      programmer: nope, we are a hardware company and have hardware patents protecting our ip.

                      management: then what are you waiting for? open source it so we don't have to waste money managing it ourselves. do I have to think of everything around here? jeez!



                      Yes, 8+ years as a programmer has throughly shattered any faith I have in the ability of 'management'...

                      Comment

                      Working...
                      X