Page 5 of 26 FirstFirst ... 3456715 ... LastLast
Results 41 to 50 of 259

Thread: Linux Developers Still Reject NVIDIA Using DMA-BUF

  1. #41
    Join Date
    Jul 2008
    Posts
    1,726

    Default

    Quote Originally Posted by RealNC View Post
    Most kernel devs are paid by AMD and Intel. Of course they reject NVidia's request. Nothing personal; just business, stopping NVidia from providing something competitive to AMD and Intel. I can't say I can blame them though. It's NVidia's own fault. If they had rooted the kernel dev team with more of their own developers, they would have been in a position to change policies.

    What sickens me is that a piece of open source software is now abused for greedy corporate politics. That's ugly.
    no kernel dev prevents Nvidia from playing nice. It is Nvidia who acts like a Disney villain and then mouth pieces like Michael blame the ones who were wronged - the kernel devs who wrote the code.

  2. #42
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,791

    Default

    The kernel allows closed source software to run on it. DMABUF, being an API that can be used externally, should be exported to be used by anyone, regardless of license. What's next? GPLing the mmap() interface and making it illegal to run non-GPL software under Linux? You seriously think that's a good thing?

    This has nothing to do with licenses. This has to do with AMD and Intel trying to stay ahead of NVidia by abusing their position within the kernel developer community.

  3. #43

    Default

    Quote Originally Posted by DaemonFC View Post
    Also, the "taint" warning is there for a good reason. It lets the user know they are running the kernel in a configuration that is totally unsupportable by either the upstream kernel developers or by the distribution that the user is running.

    Yeah, you get an Ubuntu every once in a while that claims they "support" proprietary broken crap drivers, but they really can't. Their ability to support it is the same as your ability to support it. They can *ask* the developer and *hope* that it gets fixed, some month, year, ever....
    That is not necessarily true. ZFS taints the kernel because it is not under the GPL, but it is well supported in Gentoo Linux. It is fully open source, so we can fix whatever bugs it has.

  4. #44
    Join Date
    Sep 2010
    Posts
    229

    Default

    Quote Originally Posted by gamerk2 View Post
    2) The drivers for the H/W are going to be at a VERY low level, and will basically show how NVIDIA accomplished everything in its H/W. You think AMD/Intel would like to see that information? This is especially notable, since NVIDIA has a lot of specialized components on its cards to handle certain tasks (they've hinted at such over the years...)
    You think Intel and AMD don't have the software & hardware needed to reverse engineer both the drivers and the actual hardware of their competitors? (Or the money to pay others to do the reverse engineering.)

  5. #45
    Join Date
    May 2011
    Posts
    1,500

    Default

    Who are these people that want Optimus tech on a router OS?

  6. #46

    Default

    Quote Originally Posted by phoronix View Post
    So while many Linux desktop users are quick to bash NVIDIA over their lack of proper Optimus support, right now they are also being forced down by the Linux kernel developers not wanting to allow non-GPL drivers to use this unified buffer sharing infrastructure and reducing driver interoperability.
    Linux kernel developers doesn't disallow nVidia write open source drivers. It's nVidia decision.
    They may at least release docs.

  7. #47

    Default

    Quote Originally Posted by gamerk2 View Post
    2) The drivers for the H/W are going to be at a VERY low level, and will basically show how NVIDIA accomplished everything in its H/W. You think AMD/Intel would like to see that information? This is especially notable, since NVIDIA has a lot of specialized components on its cards to handle certain tasks (they've hinted at such over the years...)
    It is possible that the drivers could be adapted to support hardware from other manufacturers, which is something that Nvidia would not want. Providing the sources would also reveal all of the hacks that are done to workaround bad hardware design decisions (e.g. the Nvidia GeForce FX 5800 Ultra), which is also something that Nvidia would not want.

    On the other hand, Nvidia does not stand to lose any vital hardware design information by providing source code and programming documentation. Intel already provides a voluminous quantity of source code and programming documentation, yet we do not see them having lost secrets because of it. Anyone who knows how hardware works will know that the exact circuit designs that implement a programming API cannot be obtained by looking at the programming API and if they are good then making a good copy based on the API is hard.
    Last edited by ryao; 10-11-2012 at 01:11 PM.

  8. #48
    Join Date
    Apr 2011
    Posts
    330

    Default

    Nvidia must release everything till the OGL3.3 under GPL, in a form of a unified_driver that is multilevel and can target various CPUs and various GPUs with LLVM and backends. Then they have to provide all the rest (OGL4+) with a closed extension package, that uses a specific path of the backend, made only for Nvidia GPUs. That extensions can be: extra compilers, extra programs for the synthesizer, extra FX, but not driver functionality like memory management, that should be open. I don't wont to refer to known security issue with Nvidia drivers, that the company didn't fix for 5 years. With that kind of unified_driver Nvidia can explore all the open source, and can use it for all operating systems.

  9. #49
    Join Date
    Oct 2009
    Posts
    2,110

    Default

    Quote Originally Posted by XorEaxEax View Post
    Bullshit, DRM exists to prevent end users from doing what they want, GPL exists to make sure end users can do whatever they want and have all that is necessary for them to do so. IIRC you work for Apple so I can see why this is so confusing for you.
    Actually, its DRM's flip side.... digital rights of the USER. Protect the USER's rights to do what they want with what they own. So DRM in this case would refer to PROTECTING the user from hostile adversaries (like NVIDIA) who would limit the user's rights to free open source software in favor of their proprietary crap.

  10. #50
    Join Date
    Oct 2009
    Posts
    2,110

    Default

    Quote Originally Posted by gilboa View Post
    Sorry, you are being *very* naive.
    Here's a number of other reasons:
    1. Your code includes licensed 3'rd party code that cannot be opened.
    It is your own fault for doing that. Either write your own code, or obtain that code under a free license.

    2. Your code includes patent-infringing code that will get you sued.
    It is your own fault for doing that. F**K YOU then.

    3. Your code is multi-platform (more on that later) and includes platform specific code that prevents it from being opened.
    Not sure how "platform specific code" would prevent it from being opened.... but even if it did, it only applies to those platform-specific PARTS of the code.

    4. Your code is being used by clients and you're prohibited by contract from releasing your code.
    Then you did a terrible job in reviewing those contracts. Time to shoot yourself in the head.

    On a personal note (Ignoring for a second that we've yet to hear the code owner's view on the matter), I believe the Linux devs are being right instead of being smart.
    nVidia is actually trying to play nice - I believe this behavior should be encouraged instead of being ignored. (E.g. trying to reach a gentleman's agreement that DMA-BUF will be made EXPORT_SYMBOL in-exchange to some documentation or headers)
    Nice? Are you on crack? They tried to SNEAK IT IN rather than what they SHOULD have done (to be nice), which is to ASK.
    Nothing wrong with ASKING POLITELY, however, even if they did, it should STILL be declined. Closed drivers have no business interacting with open drivers.

Posting Permissions

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