Post a Comment
Actually they did make an effort but the kernel devs apparently are too stubborn on the licensing issues so I guess there are huge limits on what the NVIDIA drivers can do. I am referring to the case of the devs refusing to relicense the DMA-BUF APIs - http://www.phoronix.com/scan.php?page=news_item&px=MTIwNDI
Eh ... it is such a pity. The best GPU will not work properly because of such stubborness. Don't get me wrong, they have full right to refuse to relicense this API, but it is such a bummer!
Or you could stop being ignorant and jump down from the high horse. We do not know the details of the contracts and obligations NVIDIA operates under and how many NDAs they themselves are bound by, but there definitely are atleast a handful of those and therefore it would be downright illegal for NVIDIA to do that. At most they could hire some independent developer to work on Nouveau, someone who has no access to NVIDIA's internal docs, but how much would that benefit anyone?
AMD has people on the payroll to work on the open-source radeon driver, and these people do have access to internal docs. However, even if Nvidia would do the same - pay people to work on nouveau - it wouldn't help regarding their proprietary driver and dma-buf. On the other hand, nouveau already can use dma-buf and as such support Optimus, Nvidia's involvement not necessary for that.
But basically I agree with you, people should get off their high horse regarding Nvidia. Getting involved in open-source is not as simple as they seem to think it is. Look at AMD, despite having an open-source strategy, they still have their proprietary driver. And despite people being paid by AMD to work on radeon, it isn't any better than nouveau. Both of these drivers lack hardware video decode, are quite far behind in performance, and the biggest one, both lack proper power management.
Why does radeon lack power management? Code was written, but it didn't pass legal review. So yeah, open-sourcing graphics stuff not as easy as those on the high horse want it to be.
PS. I know Intel somehow manages, their open driver has both hardware decoding and proper power management. However, one comany doing it does not mean it should be easy for others to do the same. Like you say, we have no idea how many contracts and NDAs Nvidia and AMD are bound by.
Edited 2012-11-10 06:55 UTC
Intel case showcase why aproach of AMD/Nvidia is a bit better.
Instead of X people working on Linux driver, they have 10 * X working on driver that is usable both on Win and Lin (OpenGL part, Video Decoding, etc.).
Intel have bigger team for Win, and thus they are able to make big leaps in Win driver (OGL 4.0, better perf), than Linux team.
On the other hand both AMD and Nvidia have separate efforts for SoCs drivers, and AMD choosed to pick up open source Linux drivers (but close it), instead of rewriting Catalys. It show that Bot catalyst and nvidia driver are COMPLEX.
And for sure MS FORCE closed source model for GPU drivers on Windows (Vista, 7, 8). With code SCRAMBLED and OBFUSCATED on purpose. All to "protect" its DRM subsystems.
That is also why Video engines on GPU are kept secret. Too much too loose on Win side of things.
Other area that is kept secret is Power Management, as it is area where competition is high, and innovation possible.
And 3rd highly competitive area is driver development itself. Good drivers make or break hardware. And writing those for GPU is hard.
So there are solid and sound reason for not releasing gpu driver as FLOSS.
Yes we loose a lot on that. (Eg. support for new kernels and X.orgs would come way faster for FLOSS Catalys)
But AMD/Nvdia have their reasons.
Intel is/was newcomer, so they did not care much (they had least advanced gpu hardware, and least advanced drivers), but even they keep their PM docs secret.
Edited 2012-11-10 10:50 UTC
Intel joined the GPU-game quite late, at a stage where GPU-technology was already quite well developed and understood, so they aren't bound by contracts and obligations they signed ten+ years ago while still developing the tech we see today. In other words, Intel could start from a cleaner plate and they probably already had F/OSS - source code in mind when they did, so they could develop everything with that in mind. Back when 3DFX, NVIDIA, AMD, etc. were still getting used to things there was no such thing as the F/OSS - movement and therefore the companies never planned their development efforts with that in mind.
Once you're bound by a contract it's usually very, very expensive to get out of it.
Maybe not so... http://en.wikipedia.org/wiki/Intel740#History - Intel GPUs trace their lineage from well before 3DFX era (curiously, with connection to... Lockheed Martin, of all companies)
I don't think it was the case of Intel planning for FOSS, more a side effect of their GFX chips being quite simple, not supporting many advanced (needing to be licensed) techniques.
"Protecting the integrity" by allowing some closed blobs to use dma-buf but not nvidia? Yes, all the SoC drivers that use dma-buf are closed. Sure they have a GPL component in the kernel, which is how they're allowed to use dma-buf, but that component won't do you much without the userspace blobs.
So there's no "protecting integrity" or "making a moral stance" or anything by keeping Nvidia out. It's that some vendors have managed to isolate just enough of their driver into a GPL component, while Nvidia can't because of how their driver is put together.
Also, the first two versions of dma-buf did not have those symbols exported as gpl-only: http://lists.freedesktop.org/archives/dri-devel/2012-October/029107...
You do know the thing that is called copyright, don't you? Try to get an agreement from all semi-popular GPL licensed project contributors and you might understand the issue...
nVidia can be a good FOSS citizen and move more stuff into the userland libraries.
Nvidia from company that sell to OEMs, and who see only OEMs as its clients, now see end users as their clients.
On Win it was always that way.
On Lin? Never.
So now Nvidia will not only develop Lin driver when OEMs see some functionality as needed (and they usually focused on corporate world or OpenCL/CUDA), but also will think about gamers / casual users.
Great!



