Announcement

Collapse
No announcement yet.

Linux Developers Still Reject NVIDIA Using DMA-BUF

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

  • Originally posted by Craig73 View Post
    So, why couldn't NVidia just re-implement the DMA-BUF interface for their driver, and then recompile the Intel and AMD open source drivers against that interface? (and distribute the Intel and AMD drivers in their own packages, with source.)

    Wouldn't that resolve the legal licence concerns, provide optimus and shouldn't violate the intel/amd licence? [should be easy to keep the driver current, and assuming they could easily show the bug exists on the regular intel/amd driver, just pass through intel/amd bug reports through to those projects.]

    [no expert here, don't flame, just inform me thx.]
    Maybe this could work somehow(not enough technical knowledge on the subject here), but there might be the factor of not wanting to do work for competitors, among other things. :|

    Comment


    • Originally posted by Rigaldo View Post
      Maybe this could work somehow(not enough technical knowledge on the subject here), but there might be the factor of not wanting to do work for competitors, among other things. :|
      I'm not sure what work they would be doing for competitors? If this is GPU-GPU then their proprietary solution is for them. If this is for optimus, then the whole sales pitch is that they work with the intel low powered GPU, thus the work they are doing is for themselves. Sure I suppose Intel/AMD might pick up the code and re-use it, if that's the fear then licence it accordingly to ensure enhancements work for everyone.

      On Windows, I installed one driver package that bundles both the AMD and Intel drivers... that certainly is to the benefit of AMD, and indirectly Intel as a necessary concession in AMDs (and the OEMs) broader product strategy.

      Comment


      • Originally posted by Craig73 View Post
        I'm not sure what work they would be doing for competitors? If this is GPU-GPU then their proprietary solution is for them. If this is for optimus, then the whole sales pitch is that they work with the intel low powered GPU, thus the work they are doing is for themselves. Sure I suppose Intel/AMD might pick up the code and re-use it, if that's the fear then licence it accordingly to ensure enhancements work for everyone.

        On Windows, I installed one driver package that bundles both the AMD and Intel drivers... that certainly is to the benefit of AMD, and indirectly Intel as a necessary concession in AMDs (and the OEMs) broader product strategy.
        Guess you're right. I'd like to see soon what will be done with the Optimus issue. Guess I'll just wait and see.(no Optimus here, so no direct effect on me)

        Comment


        • Originally posted by Gigetto96 View Post
          Ok, if you are right, why AMD does not publish directly its Catalyst driver as open source? Why do not directly port the Windows/Mac drivers? Only because they are dorks?
          Why Intel does not just make a direct porting of their Windows or Mac drivers? Why should they spend money paying programmers who are re-inventig something that Intel alredy has?
          Why, in general, Mesa and not open-source OpenGL drivers?

          You already told it : "there is not actual code, just some precode = how it works + standards for binary compatibility" --->THERE IS NOT THE REAL HOT STUFF. The probably PATENTED stuff...

          Go and $#@! somebody else...


          There are some things that is very bad to say. When you translate the "Open" to "Closed", then what to say, its unbelievable. Its lower than spam. OpneGL is Open. The implementations are closed and maybe patented, for example PowerVR has its own Tiled-Rasterizer that is different from Nvidias Massive-Rasterizer and different than MESA's. Also patents like S3TC are irrelevant to OpenGL, and Khronos tries to replace them with open free formats. There is not a logical reason why we don't have fast Open Drivers like Intel's for all GPUs and with the help of the companies. The most of the job is there anyway, and for free.

          Comment


          • Originally posted by XorEaxEax View Post
            You should try and understand the difference between an API and actual CODE. NVidia wants to use kernel CODE from their PROPRIETARY driver, this code has been marked as only legally linkable from GPL compatible code (EXPORT_SYMBOL_GPL) which means you cannot legally call it from PROPRIETARY code. NVidia is allowed to copy the API verbatim as many times they want, but they have to write THEIR OWN CODE.
            The symbols being exported are the API, genius. Gpl/non-gpl it makes no difference it is still the API and still not covered by copyright.

            Comment


            • The API as in the function names and calling conventions are indeed not protected by copyright. The code implementing these APIs is copyrightable however, and if it is GPL then the GPL also applies to the code linking to it.

              Comment


              • The kernel devs are essentially protecting Linux distributors from lawsuits.

                Nvidia can create and give away infringing code, but it's the distributors who would be violating the GPL by shipping it together.

                It's easier to think that Alan Cox is being mean for hating your gamez, but essentially it's Nvidia's licensing that caused all of this. They dug out a hole that ensured they'd have to do everything on their own and not use any kernel code. So they implemented most of X and kernel in their blob. This worked great for a long time, during which the kernel and X infrastructure was old and featureless, while their closed implementation was performant and full-featured. However now, when using kernel interfaces (and thus using GPL code inside the Linux kernel) is necessary to make their hardware run in the first place (due to the increasing irrelevance of discrete cards), now their decisions from the past prevent them from interacting with the kernel.

                Comment


                • Let's stick to CPU-generated graphics.

                  I think this is a bad call from the kernel developers. I also agree that nVidia should have asked first :P

                  AMD and nVidia have spent $bn's researching and developing their hardware, paying for licenses (some of which they are bound not to disclose) and these such restrictions are part and parcel of a commercial world. Some manufacturers can survive on hardware alone, others realy on a large, costly software stack to support that hardware. Fast GPU drivers are huge and take a lot of inside work.

                  I suggest those against 'prorietary drivers' to go form a competitive GPU company - spend billions of dollars researching, manufacturing, employing people and deploying such hardware - and see if they still think the same.

                  In fact, take it further as a concept - the AMD / nVidia graphics drivers don't 'fit' in the OpenSource ecosystem, right? Ok, AMD and nVidia pull out of Linux. We can just make do with Intel. That isn't anti-competitive at all, right? And one option is better than none. Let the Windows/Apple users have the optimal, heavily-invested graphics acceleration!

                  Comment


                  • You do realise that AMD is actively developing OSS drivers and releasing specifications, right?

                    And it's not a "call" from the kernel devs. Binary blobs using internal kernel interfaces are probably illegal, and no "call" can change that (the legality would have to be tested in court, of course, but no "call" can affect that either).

                    It's not like a kernel dev can make a "call" that will suddenly allow you to link binary blobs against GPL software.

                    Comment


                    • Originally posted by pingufunkybeat View Post
                      You do realise that AMD is actively developing OSS drivers and releasing specifications, right?

                      And it's not a "call" from the kernel devs. Binary blobs using internal kernel interfaces are probably illegal, and no "call" can change that (the legality would have to be tested in court, of course, but no "call" can affect that either).

                      It's not like a kernel dev can make a "call" that will suddenly allow you to link binary blobs against GPL software.
                      That's a good point: Linux can't do what Windows has been able to do for years... which seems to be par for course.

                      Comment

                      Working...
                      X