Announcement

Collapse
No announcement yet.

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

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

  • #21
    Originally posted by Sonadow View Post
    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.
    Nvidia is not the only vendor that wants to be able to link to this, and I don't see how anyone could extend a license specifically to Nvidia without running afoul of the GPL on the rest of the kernel (nobody can grant a license for the entire kernel; the whole thing is -- somewhat deliberately -- a mess of many copyright holders).

    Comment


    • #22
      Originally posted by XorEaxEax View Post
      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!
      A lot of times it's not as easy as it sounds though. The other day I was watching a presentation by Bryan Cantrill and he was reflecting back on the time that they (Sun) were trying to open up Solaris. He indicated that even with everyone on board (management included), the biggest hurdle revolved around legal issues... in particular, parts of the code that they had licensed from other entities. In the end they kind of ended up with a disaster of an "open source" release, but not necessarily because of lack of will.

      In many cases it's not as easy as just saying, "Okay boys, put the code up on git." I'm not saying that is or isn't nvidia's case... but that it is a possibility.

      Comment


      • #23
        Originally posted by johnc View Post
        In many cases it's not as easy as just saying, "Okay boys, put the code up on git." I'm not saying that is or isn't nvidia's case... but that it is a possibility.
        Well, they could at least provide datasheets. That's what AMD is doing. It doesn't have the immediate benefits of having a mature open source driver but at least it show some good attitude. Granted, the radeon drivers are well behind fglrx in terms of performance but they are quite trouble free. I switched from fglrx about two years ago and haven't looked back. I don't play games so the performance is not that important to me. And the video decoder hardware on my HD 3650 is not supported by fglrx anyhow. It only hurts a little, that it seems Linux is destined for sub par performance in such an important (at least for me) area as the desktop.

        In any case, the nouveau guys seem to be doing a terrific job without any help from nVidia. Wouldn't it have been better if they had the full datasheets from day one? I imagine nouveau would have been in much better shape by now.

        Comment


        • #24
          Originally posted by kobblestown View Post
          In any case, the nouveau guys seem to be doing a terrific job without any help from nVidia. Wouldn't it have been better if they had the full datasheets from day one? I imagine nouveau would have been in much better shape by now.
          I admit that much of me doesn't understand why some are so motivated to have open-source drivers. If the crux of it is that they want these things open to the community so that any privacy violations can be fleshed out, then I certainly see a valid argument. With all the news of the past 1-2 years regarding privacy, DRM, and some the laws that are trying to be passed, I've definitely become much more an advocate of OSS. But that aside, I don't really see why people are so adamant that nvidia open up their drivers.

          I kinda get the impression that people want nvidia to release source so that all the "goodies" could be ported over to nouveau. But that makes no sense to me. What's the point? If you already have a driver that works, why would you need to make another, especially if the case were that nvidia's was open?

          Comment


          • #25
            Originally posted by johnc View Post
            I admit that much of me doesn't understand why some are so motivated to have open-source drivers. If the crux of it is that they want these things open to the community so that any privacy violations can be fleshed out, then I certainly see a valid argument. With all the news of the past 1-2 years regarding privacy, DRM, and some the laws that are trying to be passed, I've definitely become much more an advocate of OSS. But that aside, I don't really see why people are so adamant that nvidia open up their drivers.

            I kinda get the impression that people want nvidia to release source so that all the "goodies" could be ported over to nouveau. But that makes no sense to me. What's the point? If you already have a driver that works, why would you need to make another, especially if the case were that nvidia's was open?
            Because

            - Binary drivers break stuff? (you don't need to be a Linux power user to see how AMD's and NVIDIA's binary driver cause a whole load of problems and replace parts of the standard graphics stack with their own proprietary bits)
            - Binary drivers always break every time a kernel patch is pushed out by a distro? (eg: kernel patch from 2.6.27-20 to 2.6.27-30; this driver breakage 100% guranteed to happen)
            - Open drivers mean that what is not supported officially by NVIDIA / AMD can be done so by the community? Remember that we had no chance with Optimus switchable graphics technology until only recently with the open Bumblebee project
            - Installing binary drivers sets a tainted flag on the kernel, so your bug reports to the kernel guys become thrown down to lowest priority (if at all)?

            Don't get me wrong; I do advocate the binary drivers where needed in order to get a proper experience. In fact, I do use binary drivers on my notebook in order to get the full 'Suspend + Wake + Hibernate' and superior power control support over the radeonhd driver (im using a 3 yr old distro), but the inherent hassles and risk of doing so can be a bit of a pain at times.

            Comment


            • #26
              Originally posted by johnc View Post
              But that aside, I don't really see why people are so adamant that nvidia open up their drivers.
              One word: control. If you don't have the source available under an open/free license you're completely at the mercy of your provider. Sure, NVidia has a nice track-record of supporting all their latest and quite a bit of their older gfx card. Good for them, but what happens if they go out of business tomorrow, or just decide Linux is not worth it anymore? Or, as they have done, that older gfx cards are not worth the trouble maintaining?

              This was THE reason that Richard Stallman invented the GPL in the first place. The famous story about the printer drivers.

              I myself still have a 12 year old (!) Philips Webcam (http://image.minoc.com/zd_images/200...03_camscan.jpg) that still works on Linux!
              No need to install anything, no drivers to download, just plug it in and it works. If I remember correctly Windows 98 was the last supported OS.
              I called them once to ask if they would ever make updated drivers and the answer was "why? that's a really old webcam, just buy a new one!".

              Now that's the power of Open Source, as long as there's interest somebody will continue supporting it. And if 50 years later you find a piece of equipment in the attic of your grandfather's house you could still get the code and try and see if you can make it work.

              These are probably all things you could care less about: I just want the card I bought last week to work!
              That's okay, but just remember that you're not in control, things could change tomorrow and there wouldn't be a thing you could do about it.

              Originally posted by johnc View Post
              I kinda get the impression that people want nvidia to release source so that all the "goodies" could be ported over to nouveau. But that makes no sense to me. What's the point? If you already have a driver that works, why would you need to make another, especially if the case were that nvidia's was open?
              No of course not, if the NVidia driver was open there would be no reason to have Nouveau. Although if they would open source it right now there would probably be copying to/from both sides because there are some important things that the NVidia driver does not support like KMS. Which comes back to not having any control: NVidia just refuses to support this all-important new development in the Linux kernel.

              Comment


              • #27
                Originally posted by enrico.tagliavini View Post
                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.
                The current situation on all the major ARM platforms (TI/OMAP included) is GPL kernel driver for GPU and closed userspace. So you could argue, "well, GPL kernel module, so you're ok to use EXPORT_SYMBOL_GPL()". But morally, because in the world of GPU the userspace and kernel parts are tighly coupled, that seems to me like following the letter of the law without following the spirit... so I don't think you can really argue that this situation is any better than with nvidia on the desktop.

                I'm optimistic that the situation of opensrc userspace stack improves on ARM, but it won't happen overnight. Nothing would make me happier than to be able to work on a fully opensrc graphics stack. (Please feel free to petition IMG on that topic ;-)... given the permission, I'd quite happily hack on an opensrc sgx driver on weekends and evenings.) But even when you reach the first (long) milestone of a fully functioning opensrc userspace, it will still take a long time to reach the performances levels of the proprietary driver, and when it comes to handsets/tablets, performance is everything.. so even on mali it will be the closed src driver that is shipping on devices from the factory.

                Furthermore, we do really want for nvidia to use dma-buf instead of inventing their own proprietary mechanism which wouldn't interop with the opensrc drivers. Currently the choice seems to be between those two options. One of the main purposes of dma-buf is to have a common solution to replace non-upstream vendor specific solutions for buffer sharing, and not opening up the dma-buf interface prevents that. The fact that dma-buf is mostly an interface, rather than an implementation, plus the fact that we want to get rid of vendor specific buffer sharing solutions with a common upstream mechanism, leads me to the conclusion that using EXPORT_SYMBOL() is the best choice.

                Comment


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


                  • #29
                    Originally posted by robclark View Post
                    The current situation on all the major ARM platforms (TI/OMAP included) is GPL kernel driver for GPU and closed userspace. So you could argue, "well, GPL kernel module, so you're ok to use EXPORT_SYMBOL_GPL()". But morally, because in the world of GPU the userspace and kernel parts are tighly coupled, that seems to me like following the letter of the law without following the spirit... so I don't think you can really argue that this situation is any better than with nvidia on the desktop.

                    ...

                    Furthermore, we do really want for nvidia to use dma-buf instead of inventing their own proprietary mechanism which wouldn't interop with the opensrc drivers. Currently the choice seems to be between those two options. One of the main purposes of dma-buf is to have a common solution to replace non-upstream vendor specific solutions for buffer sharing, and not opening up the dma-buf interface prevents that. The fact that dma-buf is mostly an interface, rather than an implementation, plus the fact that we want to get rid of vendor specific buffer sharing solutions with a common upstream mechanism, leads me to the conclusion that using EXPORT_SYMBOL() is the best choice.
                    If you put it like this I suppose there is little way we can argue otherwise, can we?

                    Still, I believe many others will have doubts about whether this will affect Linux in the long run. No one is going to argue about the short-term advantages, that's for sure. Again, I'm sure many will argue that this may encourage hardware vendors to 'pretend' to play nice with Linux by shipping closed driver blobs, although it can also be counter argued that these future blobs will at least be capable of using Linux's graphics stack implementation, which I suppose is still better than having said blobs replacing those system bits with its own proprietary mechanism. Like you said, following the letter of the law and not the spirit, but then again, wasn't this Linux Torvalds' principle all along? About 'using the tool that works best, and not giving a damn whether it's free or not'.

                    Just out of curiosity, since im'm very ignorant about the technicalities of the Linux graphics stack (i only know that 3D is handled by Mesa and Gallium 3D and that 2D is handled by the xfree drivers), if NVIDIA brings optimus support to Linux via DMA-BUF in its driver, will it conflict with Bumblebee's implementation of using VirtualGL? Currently, the only way to get primitive support for Optimus in Linux is to compile VirtualGL, install Bumblebee and perform some config file editing to activate the dedicated NVIDIA card as and when needed, or set it as the main rendering device in the notebook. If NVIDIA gets the go ahead to use DMA-BUF in its blob, will it mean the end of using the blob in Bumblebee and that only Nouveau will become the only driver that can be used with Bumblebee?

                    Comment


                    • #30
                      Originally posted by Janell6754 View Post
                      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...).
                      Sure...like, when Radeon / Nouveau finally achives 70-80% of the latest shipping fglrx's / NVIDIA ForceWare's performance?

                      Comment

                      Working...
                      X