Announcement

Collapse
No announcement yet.

Nouveau Driver Remains Much Slower Than NVIDIA's Official Driver

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

  • #51
    Originally posted by asdx
    If nouveau already got this good without the help from nvidia, what makes you think they won't get even better with time?

    And considering the fact that nouveau has been merged in mainline Linux as an official driver, it already tells me that it will get further development in the coming years, and that it will get better, etc.

    Also, look at what happened with Nvidia and DMA-BUF, Nvidia can't touch some Linux APIs that are GPL, they can't do things like KMS, they will get problems with module loading signing (Secure boot), etc. This is fact and they are at a huge disadvantage when compared to first class FOSS modules like nouveau/radeon/intel.

    There are many problems when it comes to blobs in a open system like Linux, and claiming that there isn't, it's just ignoring the problem.

    Blobs will get lots of problems in the future, and I don't think they have a chance to survive or remain relevant in the long run. While on the other hand, free software drivers like nouveau have lots to win and they will only get better.
    Thank you for explaining your reasoning.

    While I agree that FLOSS solutions in general have a brighter future in Linux(and I prefer them, don't get me wrong), I think there are certain limits which reverse-engineering can't overcome.
    Though you state valid points, I don't think they are showstoppers for a company like Nvidia. For example, a Microsoft singed key for Secure Boot costs $99(Fedora got one I believe), which Nvidia is probably able to pay.

    Comment


    • #52
      If you believe asdx's retarded post, you're beyond help.

      How is a driver which gets its code & data from reverse engineering the Nvidia drivers gonna support newer Nvidia Maxwell GPU architecture and future GPU architectures after Maxwell?

      First class support my ass, you'll be months and year without any working drivers, period. There will be no Optimus support either since you can't reverse engineer that, believing asdx's fantasy is hilarity at best.

      Nvidia drivers are at no disadvantage, unlike asdx's retarded view of the world. Nvidia updates their drivers to support newer kernels and X.org releases even before they're released. Nvidia even supported GLX_EXT_buffer_age extension long before open source drivers did.

      Outperforming the Nvidia drivers? Still waiting for that to happen aka not ever gonna happen, even the open source radeon driver with AMD's partial specs release still is significantly slower than the buggy fglrx/Catalyst crap. There's no OpenGL 3.3 support when Nvidia drivers had that 3 years ago, Nvidia now ships OpenGL 4.3 support in the Nvidia drivers.

      Comment


      • #53
        Originally posted by GT220 View Post
        If you believe asdx's retarded post, you're beyond help.

        How is a driver which gets its code & data from reverse engineering the Nvidia drivers gonna support newer Nvidia Maxwell GPU architecture and future GPU architectures after Maxwell?
        They won't need to. You are forgetting that Linux has not come to this level of HW support over night. One change was required to trigger another etc, so that manufacturers would eventually give a damn what anyone thinks about Linux support. It was long and tough and some natural selection mechanisms were needed to reward open ones and punish others, but now having actual documentation for HW and often even technical support and even active development is not unheard of anymore.

        Competition works. Btter the radeon driver works, mor incentive it will put on AMD to channel its resources there instead of mangling fglrx. Also, stronger pressure will it put on nVidia to formally join the Nouveau or form the equivalent and kick the project into high gear.

        So, chances are reverse engineering won't be needed for long...

        Comment


        • #54
          Originally posted by GT220 View Post
          If you believe asdx's retarded post, you're beyond help.

          How is a driver which gets its code & data from reverse engineering the Nvidia drivers gonna support newer Nvidia Maxwell GPU architecture and future GPU architectures after Maxwell?

          First class support my ass, you'll be months and year without any working drivers, period. There will be no Optimus support either since you can't reverse engineer that, believing asdx's fantasy is hilarity at best.

          Nvidia drivers are at no disadvantage, unlike asdx's retarded view of the world. Nvidia updates their drivers to support newer kernels and X.org releases even before they're released. Nvidia even supported GLX_EXT_buffer_age extension long before open source drivers did.

          Outperforming the Nvidia drivers? Still waiting for that to happen aka not ever gonna happen, even the open source radeon driver with AMD's partial specs release still is significantly slower than the buggy fglrx/Catalyst crap. There's no OpenGL 3.3 support when Nvidia drivers had that 3 years ago, Nvidia now ships OpenGL 4.3 support in the Nvidia drivers.
          Do you run Nvidia proprietary nforce network drivers?

          Or the reverse-engineered open ones?

          Come on, be consistent, use the closed ones. Tell us how that works out for you.

          Comment


          • #55
            I use Intel Z77 chipset motherboard with my Ivy Bridge CPU, how exactly am I gonna use nForce drivers? Typical retarded people like pingufunkybeat trying to troll without using any semblance of a brain you might have, but nice try though at trolling.

            Comment


            • #56
              One more thing about open source drivers:

              You need tehm even if you don't use them.

              1. Sooner or later you will get into the situation where your closed source drivers won't work, like on the superfresh kernel that you decided to use ffor some reason or with new xorg with some capabilites that you'd care to try, or with Wayland etc. In such situations open-source can be great, even if temporary solution.

              2. Even if you totally, asbsolutely never come to aforementioned problem, it is always advantageous to have a second choice, even if you don't plan to actually use it. Its _mere_presence_ creates the pressure on the closed-blob driver creators to compete to at least some level and do a better job they would do otherwise.

              3. Support for open-source imply openness and transparency, so manufacturer have less shady spots where they can do shoddy job or hide spyware and there is bigger chance for them being caught and punished even with binary blobs.
              Last edited by Brane215; 05 January 2013, 08:13 PM.

              Comment


              • #57
                Originally posted by asdx
                Retarded is your post insulting people and implying that nothing could or will change for the betterment of Linux and open source.

                I can't believe how short-sighted people like you are.

                Haven't you learned anything from Linux and its development history? Or from hardware support and development on Linux?

                Please go back and look at Linux history. There are many examples/cases where open source components replaced proprietary software on Linux.

                History will only repeat itself in this case, it's inevitable.
                Right, and where is CrossFireX and SLi support on the open drivers?

                Multi-GPU setups which were already existent way back in 2006 and still not supported with the open drivers? 6 years and still nothing from the open drivers?

                C'mon, if you want to troll, troll with some intelligence. There are people with professional notebooks and desktop setups with multi-GPU configurations who have been waiting for years just to get CrossFire and SLi support from the open drivers since day 1. And these are technologies which are almost guaranteed never to come to the open drivers because no degree of reverse engineering is going to cut it. Just because you don't use your computer for the kind of professional work that people in Windows take for granted does not give you the right to demand that they live without it in Linux. Neither does it give you the right to demand that businesses open their stuff. That fact that you even think that you can demand for such things shows just how much Linux users think they are entitled to when they don't even have the numbers to back their demands. If you have a market share of 50%, then perhaps those demands are valid, but 1.4%? Right, keep dreaming.

                And I also don't need to mention the hypocrisy displayed over the whole 'open-source makes everything cross-platform compatible' nonsense. Open source everything so that nobody has unfair advantages? So why are there people who are in favour of Linux-specific extensions made to key pieces of a Linux distribution stack (systemd is a very good example) that makes it completely incompatible with the BSDs? Or even the religious war that BSD is some devil which should be condemned just because Linux holds the lion's share of the alternative operating system market? By that logic the whole world, and not just AMD and Nvidia, can simply condemn Linux to death because Windows holds a 70% market share of mainstream desktop operating systems. People tout open systems and cross platform compatibility while trying to defend all actions that undermine BSD compatibility when major changes are made to the Linux software stack with claims that BSD is not relevant anymore because Linux's market share dwarves it (while conveniently forgetting that Windows crushes Linux and OS X combined in the desktop OS front). Hypocrisy at its finest, no?

                And all you have been doing is gloating how Nvidia cannot use DMA-BUF. Well listen up, they don't NEED to. Nvidia has already got their own proprietary form of KMS in their blob, so they sure as hell don't need to adhere to your 'standards' of how KMS should be implemented in Linux. And last I heard, they are already in the process of recreating their own proprietary version of DMA-BUF within the blob to get Optimus working, so all that 'I-told-you-so' attitude over DMF-BUF is of no relevance anymore. And you only have Alan Cox's inflexibility to blame for that; by forcing GPL symbols only you have ended up with two versions of it that does the same purpose, and I am going to bet on it that Nvidia's proprietary implementation of DMA-BUF will surpass the original GPL-ed version in capabilities when released.

                I'm not blind to the benefits of open software, and anybody with half a brain can see how an ideal world where all software is open will make computing so much easier with respect to hardware support and drivers. But that world is not going to happen in my lifetime (nor the 2 generations on my estimation), so I don't see any reason to work towards it. If it's meant to happen, it will happen whether anyone likes it or not.
                Last edited by Sonadow; 05 January 2013, 10:50 PM.

                Comment


                • #58
                  Originally posted by asdx
                  Where is their proprietary DMA-BUF implementation? What is it called?
                  It's inside the blob, what are we even supposed to know what it is called? The only known fact is that Nvidia is completely within their means (legally and financially) to recreate a proprietary implementation of DMA-BUF to get Optimus working on Linux if they don't want to deal with the GPL restrictions of DMA-BUF.

                  For all we know it might not even be called DMA-BUF anymore once Nvidia is done with it, but just part of the driver blob that allows for similar functionality. Heck, nobody except Nvidia knows what they are doing. All we can do is only speculate on what they can come up with based on dribs and drabs of information posted here and there.

                  And all I can say if that if Optimus ever comes to the blob via a proprietary implementation of DMA-BUF, Alan Cox is only going to have himself to blame for being the catalyst that caused this duplication. To quote Steve Jobs (even though he's like some devil to most people):

                  We have to let go of this notion that for Apple to win Microsoft has to lose… I think if we want Microsoft Office on the Mac, we better treat the company that puts it out with a little bit of gratitude.
                  I wish I can say the same thing for the Linux kernel and library developers.
                  Last edited by Sonadow; 05 January 2013, 11:04 PM.

                  Comment


                  • #59
                    Originally posted by asdx
                    If Nvidia wanted to use the DMA-BUF interface, why not release their code? Why not help the nouveau team and improve nouveau? What's preventing them? As you said, they have the resources and are financially stable to do so. They just don't want it..
                    If somebody doesn't want to do something, they have their reasons for not doing it. Alan has his reason for not wanting to oopen up DMA-BUF much like Nvidia has its reason for not wanting to open up their code.

                    Nvidia has already made it very clear that they won't budge on opening their code, so no amount of convincing can make them change their minds. However, Linux users want Optimus. Nvidia doesn't mind providing that as long as they can use DMA-BUF so that they don't have to reinvent the wheel. But Alan's refusal to open up DMA-BUF means that he is single-handedly denying all the features to those who actually want them, and result is that Nvidia can now choose to
                    • simply disregard Optimus (which I and at least 2 other people have pointed out before, is useless under Nouveau because its weak performance defeats the whole purpose Optimus was originally created), or
                    • create their own proprietary implementation of DMA-BUF and splinter an existing kernel feature which will most likely see greater advancements and improvement under Nvidia than the original because of their freedom to work independently from the kernel tree and integrate it deeply with the blob, which will in turn cause the devs to cry foul because Nvidia is able to advance their proprietary splinter much faster without needing to contribute any desirable improvements back


                    It's not my role to debate whether Alan's or Nvidia's decision are acceptable or not. All I see are possible outcomes, and as far as I am concerned, if the second alternative really does happen and Nvidia's proprietary, clean-room reimplementation of DMA-BUF does really end up far surpassing the quality and performance of the original GPL-ed DMA-BUF, Alan has only himself to blame since Nvidia is not legally required to contribute anything back to the original DMA-BUF, especially since the proprietary splinter is definitely going to have multiple extensions that will be desirable for performance.

                    And even if the 2nd alternative does not happen and Nvidia simply chooses to drop Optimus for Linux, it will take years for Nouveau to come close to the blob's performance and power saving capabilities. Optimus is pointless if all the user is going to see is a weak performance boost that drains more power for what it is worth. It is already a known fact that Nouveau, which is already not competitive eith the blob at its underclocked levels, does not scale properly in performance even if the reclocking feature is supported. And by then, Nvidia may probably start shipping even newer locked-down GPU-switching solutions that will again require extensive reverse engineering to even provide primitive support within Linux.

                    And the worst part? All of these can be potentially avoided if Nvidia is allowed to use DMA-BUF; DMA-BUF won't get splintered, and Linux users get feature parity with Windows users on launch day via the blob
                    Last edited by Sonadow; 06 January 2013, 12:08 AM.

                    Comment


                    • #60
                      Originally posted by Sonadow View Post
                      Right, and where is CrossFireX and SLi support on the open drivers?

                      Multi-GPU setups which were already existent way back in 2006 and still not supported with the open drivers? 6 years and still nothing from the open drivers?
                      Where is documenntation about the HW product that would enable good SW development ( datasheets, register models, user manuals) ?

                      Why are you directly comparing project based solely on reverse engineering with the one, based on 100% manufacturers suport ?

                      Comment

                      Working...
                      X