Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 44

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

  1. #21
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    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!

  2. #22
    Join Date
    Feb 2012
    Posts
    111

    Default

    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.

  3. #23
    Join Date
    Oct 2009
    Posts
    845

    Default

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

  4. #24
    Join Date
    Jan 2008
    Posts
    772

    Default

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

  5. #25
    Join Date
    May 2011
    Posts
    1,295

    Default

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

  6. #26
    Join Date
    Apr 2011
    Location
    Sofia, Bulgaria
    Posts
    74

    Default

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

  7. #27
    Join Date
    May 2011
    Posts
    1,295

    Default

    Quote 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?

  8. #28
    Join Date
    Jun 2009
    Posts
    504

    Default

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

  9. #29
    Join Date
    May 2008
    Posts
    73

    Default

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

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

  10. #30
    Join Date
    Sep 2011
    Posts
    180

    Default

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

Posting Permissions

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