Nouveau Driver Remains Much Slower Than NVIDIA's Official Driver

[asdx]

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

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.

[Sonadow]

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.

[asdx]

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.

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.

Where is their proprietary DMA-BUF implementation? What is it called?

[Sonadow]

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.

[asdx]

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):



I wish I can say the same thing for the Linux kernel and library developers.

I don't understand why you talk that way about Alan Cox, I don't think he did anything wrong here, he only acted in a way that he protects his code and he has all the right to do so, as being the author of said code.

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.

So nvidia is the one to blame here, not Alan Cox.

Nvidia could play well and they know how to, but they don't want to, so I don't see why you would want to blame someone else, Alan Cox in this case, when Nvidia is the one in the wrong.

[Sonadow]

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

[Brane215]

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 ?

[Brane215]

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.

Hand-of sleight trick. You used two various definitions for "open" in same sentence.

[Sonadow]

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 ?

AMD opened up their documentation, and what happened with RadeonSI? One whole year and 2D accel over GLAMOR is still not even at an acceptable level.

Creative released their sound card drivers under the GPL, and what happened? Not a single person even bothered to pick up the driver and extend it to work with the newer sound cards produced by Creative.

Why should I not compare the reverse-engineered projects when the community has not even proven itself to be capable of walking the talk with vendor-provided specifications?

[Brane215]

AMD opened up their documentation, and what happened with RadeonSI? One whole year and 2D accel over GLAMOR is still not even at an acceptable level.

Not even close. Fglrx team had ALL the documentation and access to HW all that intimate internal docs that AMD didn't care to release to anyone outside.
Also, fglrx team didn't have to live of solar energy. They got their wages for actual development.

Open source team got just smallish part of the documentation and farewell.

Creative released their sound card drivers under the GPL, and what happened? Not a single person even bothered to pick up the driver and extend it to work with the newer sound cards produced by Creative.

Which obviously mirrored market forces of open source. SW gets written where it is needed and there is sufficient interest fot it to get written.
I don't know all details around Creatie, but IIRC they did not release all info. Just like VIA for their graphics.

When I byu some piece of HW, I expect to have drivers WITH the source and documentation for the case if I decide to check or change something. Just showing some pdf on some page ( let alone that being all needed, relevant and up-to-date docs) just isn't enough for me.

Why should I not compare the reverse-engineered projects when the community has not even proven itself to be capable of walking the talk with vendor-provided specifications?

For the same reason that you can't put to the same metrics aftermaket efforts of garage entusiasts with manufacturers service of upgrading car engine or handling.

Between them is a light year of difference in-house information, equipment availability and last but not least - MONEY.