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 artivision View Post
    OK agent, I'm this close to $#@! you. The entire page of comments is irrelevant and wrong because are based to you comment that is also wrong. The reference implementation of OpenGL drivers IS OPEN. Anybody is welcome to look at the reference code (there is not actual code, just some precode = how it works + standards for binary compatibility), without the need to Open or Close anything. Its Nvidias fault and AMDs also: With HD5000 AMD it self said that they will try with HD8000 to have only Open drivers. Fuck both. If only i wasn't gamer!
    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...

    Comment


    • ... More on OpenGL...

      The public, open, part of OpenGL is how to use a driver that already exist. Not how to program an OpenGL drivere.
      They give you documentation about how to display a cube with OpenGL, what OpenGL call you need, for example. They do not tell you how the OpenGL driver actually draws the cube for you, they do not tell you how the OpenGL call works inside. That is the problem. That is the reason behind the bugs and the sluggishness of open source dirvers...
      Who programs the Mesa drivers is in the same position of the Wine programmers: they know what each library call is supposed to do, but not HOW the result is achieved in the original thing..

      This is what I undestood...

      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...
        Get some information before you start spreading misinformation.
        I won't comment on a reference opengl specification, as I have no knowledge in that area. I do know that some mandatory parts of openGL are covered by patents (namely s3tc and the floating point extension). These two extensions are implemented for mesa, but not merged in master.

        Binary graphic drivers contain a lot more than just the openGL specification. One thing that comes to mind is video decoding. These are patented technologies, and most likely not even completely designed internally -> meaning they licensed it from a third party. This is where the shitstorm is brewing, and why the blobs won't be opensourced. Another reason is paranoid guarding of some magic. But that's a non-reason.
        Porting a driver to another platform is almost a complete rewrite (if you don't have the infrastructure ready beforehand) -> this is why Intel doesn't port, and why nvidia and AMD do (their drivers have a shared core). Plus nothing guarantees that Intel already has an opengl implementation, they surely have a DX implementation, maybe opengl runs on top of it... (this is only speculation)

        Bottom line is :
        - opensourcing blobs is not possible due to everything they ship (do you really think that an OpenGL implementation could be > 100MB in size, after compilationn?).
        - With the current state of software patents, mesa will not be able to safely implement all opengl features.

        Serafean

        Edit :
        Who programs the Mesa drivers is in the same position of the Wine programmers: they know what each library call is supposed to do, but not HOW the result is achieved in the original thing..
        Mesa devs at least don't need to have bug-compatibility And IMO your reason for slugishness is incorrect : you know what you're supposed to do, and you have perfect knowledge of the hardware, so you do it in the optimal way. IMO the true reason is that mesa and its drivers is still catching up on features, and in a development process optimisations come after feature-completeness...
        Last edited by Serafean; 10-16-2012, 08:54 AM.

        Comment


        • The point is, that (also) due to the patents, who develop open source drivers can not have read the code of the blobs. So, they are required to re-invent the wheel.
          (Intel for sure has OpenGL drivers, because the Macs use OpenGL. And if porting the driver to another platform was almost a complete rewrite, for sure it would be a much faster rewrite than what we are experimenting with the open source driver...)

          Originally posted by Serafean View Post
          Get some information before you start spreading misinformation.
          I won't comment on a reference opengl specification, as I have no knowledge in that area. I do know that some mandatory parts of openGL are covered by patents (namely s3tc and the floating point extension). These two extensions are implemented for mesa, but not merged in master.

          Binary graphic drivers contain a lot more than just the openGL specification. One thing that comes to mind is video decoding. These are patented technologies, and most likely not even completely designed internally -> meaning they licensed it from a third party. This is where the shitstorm is brewing, and why the blobs won't be opensourced. Another reason is paranoid guarding of some magic. But that's a non-reason.
          Porting a driver to another platform is almost a complete rewrite (if you don't have the infrastructure ready beforehand) -> this is why Intel doesn't port, and why nvidia and AMD do (their drivers have a shared core). Plus nothing guarantees that Intel already has an opengl implementation, they surely have a DX implementation, maybe opengl runs on top of it... (this is only speculation)

          Bottom line is :
          - opensourcing blobs is not possible due to everything they ship (do you really think that an OpenGL implementation could be > 100MB in size, after compilationn?).
          - With the current state of software patents, mesa will not be able to safely implement all opengl features.

          Serafean

          Edit : Mesa devs at least don't need to have bug-compatibility And IMO your reason for slugishness is incorrect : you know what you're supposed to do, and you have perfect knowledge of the hardware, so you do it in the optimal way. IMO the true reason is that mesa and its drivers is still catching up on features, and in a development process optimisations come after feature-completeness...

          Comment


          • Originally posted by entropy View Post
            What I don't get, how would that allow to implement Optimus(TM) between an intel IGP and an Nvidia GPU?
            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.]

            Comment


            • 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