Slashdot Mirror
Alan Cox to NVIDIA: You Can't Use DMA-BUF
DMA-BUF is a recent kernel feature that allows multiple GPUs to quickly copy data into each others' framebuffers. A use case would be the NVIDIA Optimus that pairs a fast GPU with an Intel integrated GPU, where the NVIDIA GPU writes into the Intel framebuffer when it is active. But, NVIDIA won't be able to use this infrastructure because it's GPL. Alan Cox replied on LKML to a request from one of their engineers to mark the API non-GPL: "NAK. This needs at the very least the approval of all rights holders for
the files concerned and all code exposed by this change. Also I'd note if you are trying to do this for the purpose of combining
it with proprietary code then you are still in my view as a (and the view
of many other) rights holder to the kernel likely to be in breach
of the GPL requirements for a derivative work. You may consider that
formal notification of my viewpoint. Your corporate legal team can
explain to you why the fact you are now aware of my view is important to
them."
The rest of the thread is worth a read (a guy from RedHat agrees that this code is GPL and cannot become non-GPL without relicensing from a major subset of graphics system contributors). This has a ripple effect: it means that all of the ARM SoC GPU drivers can't use it either, and it may prevent any proprietary drivers for the proposed DRI version 3.
As AC since I'm sure this will garner much hate, but this is honest speculation with the intent of stoking real discussion:
1. NVIDIA and Intel want to use a new whiz-bang feature in the Linux kernel to bring faster and more feature-rich graphics to Linux. This is a good thing, a very good thing.
2. The current licensing in the kernel makes that impossible unless NVIDIA open sources its IP. Whether this is good is questionable because:
a. It means NVIDIA has to give up a competitive edge OR
b. NVIDIA has to write code and implement hardware in a manner that specifically prevents them from having a competitive edge.
3. NVIDIA's only other option is massive duplication of effort and a fork of the Linux kernel. This is a questionable premise.
So, given that NVIDIA's choice is to give up a competitive edge or to intentionally implement its feature set in an obstructionist manner, how is the GPL "good" in this case?
And this is why graphics support will always be a third class citizen on linux.
Congratz!
They woul dhave a bad time coming along anyway, since they can't be compatible with the secure boot (UEFI) way of working (workaround if one prefers), that is being adopted by major distributions: all Kernel level code, and X11 code, will have to be signed to work out of the box in a UEFI restricted boot environment. And any distro that would sign binary code coming from NVIDIA or whoever else would be mad.
It may be we get some months across a new "no working 3d drivers" dark ages on the Linux desktop, but one way or the other, the time for proprietary drivers is past.
-><- no
Actually, he's telling them that they can use DMA-BUF in their video drivers. And so can anyone else, provided those drivers are released under GPL.
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
No, they would have called this API from their proprietary binary blob drivers, not copied or modified the code implementing it.
And if it leads hardware vendors to avoid writing sophisticated drivers for Linux (a far more likely outcome), what then?
Why would nvidia want to deal with fanatics like this when they can just ignore them?
Nvidia isn't going to GPL its drivers and it couldn't do so even if it wanted to.
Of course Nvidia could GPL its drivers. That "they can't do it" been said ever since the first proprietary Nvidia Linux driver, and back then it was blamed on non-specified technology licensed from SGI. SGI then stated publicly that they had absolutely no problem with their technology ending up in a GPL'd Linux driver.
It is just a pitiful excuse. Luckily, between "secure boot" and this, the excuse will not last much longer. Then it will be either GPL or nothing at all.
Finally! A year of moderation! Ready for 2019?
You are getting muddled. The googVorc case was if oracle could copy right the API (that is, the list of function name, their hierarchy, intput/outputs) and prevent google from doing a clean room implementation that complies with their API. In this case, they are saying NVIDIA can't make an API call _into their code_ and ship proprietary bundles linked against their GPL library. NVIDIA could do a clean-room re-implementation of the kernel if they wanted to, but that is not what is going on here.
If you don't have the constraint that linking is derivative then the whole notion of copy-left is dead, as you can fully use any library in any application. The authors are giving you a license to use their code for free, they can put what ever restrictions on that license they want.
The Intel drivers are a better example: they are rock solid, Intel has contributed tons toward advancing the graphics stack, etc. AMD has maintained a split development effort: hiring external companies and providing some docs for the Free drivers, all the while putting their main development effort into their proprietary FGLRX driver. I suspect that's the real reason their drivers are kind of crap.
HAL 7000, fewer features than the HAL 9000, but just as homicidal!
Okay, great, if the world was perfect you'd have a great day! Yay!
But, what if this change means that nVidia and all ARM graphics drivers come up with their own non-GPL kernel API, it would probably not be compatible with DMA-BUF, and that means that the graphics drivers in the Linux kernel - both open source and not - would pick and choose which buffer sharing mechanism they support/use, leaving the rest out in the cold. This situation just so happens to negate the ENTIRE purpose DMA-BUF was created for, namely, to act as a SINGLE way for ALL drivers to share and pass buffers around. So, instead of creating a BETTER situation where all graphics drivers are compatible with each other (even the proprietary ones), we have a crappy situation that we've continued to have since day one - proprietary and open source graphics driver not playing nice with each other.
It's even in your short term and long term best interests to get everybody to use DMA-BUF, because the faster that happens the easier it is to use Linux, the more people start to use Linux, and Linux users slowly start to become more and more relevant to driver manufacturers to the point that, like Mac users, they become a profitable segment of the computer using population (note that this is both for desktop users with nVidia cards, or short term uses, and all ARM drivers for embedded devices which are becoming more popular, or long term uses), and graphics developers start to support them as best they can (read: supporting open source driver development).
While this is happening - in other words, while the world is ruled by proprietary graphics drivers because the open source ones suck (as is currently the case, and although it's improving is likely to continue to be the case for at least another two years), you can have your Left 4 Dead 2 on Linux with the proprietary nVidia driver that it needs, you can have lower power usage on all Linux laptops because Intel and nVidia cards can share buffers and therefore change which card is actively processing depending on what is running, and you can actually have useful drivers for all embedded devices until open source graphics drivers are available (whenever that happens, as it is barely on the radar of developers at this point).
So, you (and Alan Cox) can be complete dicks about this and hold the Linux desktop and Linux embedded devices with decent drivers back for years because nobody bothers to support such a tiny market with open source drivers, or you can allow proprietary graphics card manufacturers to keep their hold on graphics drivers for a few years and keep the vast majority of users happy because they have a device that works well enough (even though it doesn't have open source graphics drivers) UNTIL the community develops open source drivers themselves.
So, what's more important to you, possibly helping proprietary vendors temporarily and helping desktop and embedded users out tremendously for the next few years; or keeping your kernel untainted by proprietary crap, unhelpful to proprietary vendors, and keeping the kernel the same mess it has always been, and pissing off the vast majority of desktop and embedded users for years?
I would argue that Valve is only porting Steam and their games to Linux because the nVidia graphics drivers exist (because their games require OpenGL 4+, which isn't supported, and will not be support for years, by open source drivers). And yet, them porting their AAA title games is going to tremendously help Linux break out of its insignificant shell on the desktop - which will drive adoption, drive demand for Linux, and ultimately drive the demand for open source drivers anyway.
So, take a deep breath, calm down, and just accept the fact that allowing something to be temporarily imperfect in your world is a good trade off to make to have a much better world a few years from now.
Furthermore, DRI3 (the userspace API) will become dependent on DMA-BUF once it is developed, which means that DMA-BUF will become a usersp
Are you hating or just misinformed? NVIDIA ranks second in terms of total lines changed for the ARM kernel, and fourth in terms of number of changesets for all employers or organizations. That's sharing.
The only thing they don't share is their graphics drivers - which seems like a fair trade overall. nVidia has licensed patented code which they couldn't share even if they wanted to.
NVIDIA will likely just build their own DMA memcpy routine - because copying memory is SOOO unique.
Full disclosure: I develop (unrelated) proprietary kernel modules, I'm very familiar with the licensing, patent and copyright issues and we work within the GPL limits defined by the kernel team.
They have many licensed components in their code. So they have to remove all that and rework it, and do it in such a fashion as to not get sued by those companies (who might claim that the nVidia programmers couldn't work on the new code since they'd seen the licensed code). This isn't just some more minor features such as S3 texture compression, but OpenGL itself. Go look it up, OpenGL isn't a free "do whatever you like" setup. There is licensing for it for companies like nVidia.
Even worse is that because the issue isn't just opening the source, but actually GPLing it, that makes it so much harder. Some of their licensed components are things the companies might be ok with source distribution. However nVidia doesn't have the right to relicense that code under the GPL. So even if they opened it, it wouldn't do any good as the GPL is what is required here.
So the argument of "just open the driver" is somewhat unrealistic. It isn't just that nVidia likes to have a competitive edge, though they surely do, but that it would be a major issue and a lot more work to try and do so, if it were even possible.
Again, take the OpenGL issue since it is a pretty fundamental one. nVidia licenses the code and has the latest OpenGL 4.3 implemented on cards that support it. Ok so let's say they decide to grab the Mesa code for an OSS branch. It's MIT license which is GPL compatible so good to go right? Well, not really. Mesa is OpenGL 3.1, 3 years out of date, and it only recently got that. So they can either deal without a bunch of features on all platforms, have two different drivers one full featured on Windows and such, one with less features, or they can invest a ton of work to try and make their own up to date OSS OpenGL implementation and hope they aren't sued.
None of those sound like very good uses of resources.
PSST, this is an API called marked in such a way that only GPL modules are allowed to call it.
It's a deliberate act of douchbaggery by kernel developers to force manufacturers to open source their drivers, not to steal code from the kernel.
No, this is why linux exists in the first place.
Please don't echo the Microsoft buffoonery of calling the GPL "viral".
If it's viral it's a virus you choose to contract.
A couple years ago, back when they had the upper hand, NVIDIA did not even open up the drivers for their ethernet chips, $DEITY knows what trade secrets could have been hidden in a ethernet driver.
Also, don't say that they're not opening the code because it's licensed by third parties: they don't even release documentation for their chips. The truth is that they don't care about open source, and will behave only when forced to.
Full disclosure: Linus Torvalds develops the linux kernel, he's very vamiliar with the licensing, patent and copyright issues and relationships with NVIDIA, and sent them to "fuck themselves" (sic.).
Linux developers are not trying to "force" anybody to do anything. Nvidia is trying to force the linux community to accept their unacceptable "super secret" blob into the kernel agains the linux community's development and participatation standards.
If I showed up on your doorstep and said "you have to let me use your bathroom and your kitchen, but I am not going to wash my hands or put on pants" you would not be "forcing" me to (anything) by saying that my intended pantless, unwashed use of your facilities was unacceptable.
The Linux community is telling nvidia "we use soap and pants here, if you won't do likewise, we don't feel like accomodating you."
Nvidia _knows_ they want in, otherwise they wouldent be trying to get in, Linux Don't Care if they come or not, but if they come they need pants...
Requiring someone to meet minimum standards for participation is not "forcing them" to do anything,
No pants, no access is not an unreasonable position.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
The preceeding mail from Jan-2012 mentions the reason why they need to have the drivers that interact with the interface gpl-ed:
'A bug on a driver using such low-level interface could cause side effects
at the wrong places. In order to handle such bugs, the developers and the
maintainers of both subsystems need to see the source code of the entire
pipeline, with is not possible if is there any non-GPL'd driver.
NAK
Mauro.'
Linux developers don't care, nor shoud they, about the decision of one company to play nice or not.
Linux kernel developers have been letting Nvidia get away with the whole "binary blob" thing for a long time. Nvidia has taken no real steps to come into conformance with the GPL requirements. They keep getting a pass for their bad citizenship.
Eventually bad actors (Nvidia) either have to shape up, or they need to ship out.
At the moment Nvidia is freeloading on the linux kernel. They are putting themselves in there for free. Now they are asking to break even more rules, or more accurately, to have the rules changed in the name of their personal interests. Nvidia has fouled their own bed, but now they are whining that they don't want to have to lie in the filth of their own making. They are a full grown company. They know what they _ought_ to be doing. They want a pass to have things their own way regardless.
Sometimes you have to tell a spoilt child that they don't get the lolly this time.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
I thought Oracle v. Google said APIs weren't copyrightable. As such, GPL-only APIs make no sense because the API can't be copyrighted to begin with.
You're wrong.
It is fine for someone to go and make a new, compatible implementation of the DMA-BUF API, with the same calling conventions etc., and license it however they wish. That is what the Oracle vs Google judgement said.
It is not okay to link your code into the GPL version of the DMA-BUF API unless your code is also GPL'd. That is something different.
Pirate Party UK
I've never really understood so much of the background on this. I really don't. Nvidia are probably *the only* fucking company that really went the whole way and really release the right 'kind of ' full drivers for Linux. Yes, they are closed source binary. Yes, they are proprietry. Yes, they don't comply with religious level political idealogy. But they contribute in a less than optimal way to your platform.
And your platform, at least in the short and medium term would be vastly shittier without their efforts.
So, next you publicly go viral dropping a bucket of shit over them. Their response has been moderatly to try to come in and talk, make changes and be more of a interactive unit with you. I bet that the devs inside the company are probably very pro making progress but face real world limits of legal and other things that they themselves are not empowered to fundamentally change.
I'm not surprised at Alan's answer - but here is my raw take on this. What would have been the better way forward was to take their request and frame it globally to that group of people and put Nvidia's request forward. I appreciate that many would likely answer no, and I appreciate this would perhaps not be what Nvidia wanted, but it would have opened a bridge for interaction and perhaps longer term bridge building. Instead, they get a fuck you, fuck your company, and do this our way or the highway.; What were Nvidia trying to do? Provide an answer to the problem they had a bucket of shit thrown over them in public about. ie - trying to solve a problem they were abused about.
The benefit of doing this is fixing something in linux - albeit with a closed driver that people asked for. Linux users asked for this. Linux Kernal people bitched about it. Linux coders refusing to help provide this moves this off being a purely Nvidia are a bunch of fucks to shooting your own platform in both feet.
I don't fucking get it. These bits of code I presume are already fully in Linux. Sat there in daylight .Refusing to let Nvidia use them to help you do something_you_asked for is demented. Or rather - let me reframe that - Its really lame to not engage in a process to find a way forward instead of ramming the ideology down the throat of a vendor who is a closed source bunch - but have come to try and engage with you on a problem.
Let me put it more plainly. Linux needs Nvidia more than Nvidia needs linux - but together you make something that is symbiotic. You think your mythical Ubuintu tablets are going to surface on the very proprietry ARM platform by not getting down and working with people like Nvidia on problems. Linux won't run 'well' on their platform without their help. You want to be there? Take your heads out of your asses.
As much as Linux gets hobbled by closed source folks not playing the game, its just as hobbled by killing off their interactions and opportunities by being too hard headed about the religio-political idealogy.
And a fucking note to the Intel GPU Linux fanboys. The drivers have almost always been shit. And the hardware is low end garbage. I'll take a Linux box with Nvidia GPU *EVERY fucking time over intel gfx. Every time.
We`re all equal
No, it's not.
You and everyone KEEP presuming the only space at stake here. There's another and they want to play in this space badly because it's big-bucks for them or they wouldn't have done it in the first place. (Hint: There was no good reason for the Linux drivers they've made to date- because there really wasn't a market for those end-user drivers (these are treated as such by the community, but they're not really for the consumer market...) until recently in the first place.
Think engineering workstations (early reasons...seriously, for both AMD and NVidia...) and supercomputing clusters using GPGPU computation (There's a reason for the opening of AMD's stuff...that's part of that.).
If they want to play in that space...they're going to have to change attitudes, much like AMD did.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
The GPU is no anymore a peripheral device, it's more and more integrated on the same die as the CPU. Intel, AMD or ARM have plans to lowering the difference even more on how GPU and CPU will exchange data and will view the rest of the system. Basically, the CPU cores and GPU cores will share the same location into the architecture. This move is not so different from the integration of the FPU core into the CPU that have existed back to the 80486/68040 days. About ten years before the FPU integration, the FPU chips was a lucrative business: this part was so expensive that it was an option that only a few can buy. Not anymore, FPU less CPU are now only found in the lower part of the ARM embedded market. There is no x86_64 chip without FPU by the design of the instruction set. GPU is the next core to get the same integration.
What this means ?
First, since Nvidia don't own a licence to build x86_64 chip, the game is actually already over for them. There known that since the failed merge talk with AMD and explain why there focus on the high end and ARM chips since this time. This also explain why Linus Torvalds "fuck you Nvidia" response was focused on the Tegra ARM SoC despite the fact that the original question was about a x86_64 laptop.
Secondly, Intel and AMD known that sooner or later, the GPU core will be so integrated with the CPU core that there cannot be managed anymore by only a driver to do in a efficient way there new roles aside of the graphic display. The trigger point will probably be when the GPU will passe on the CPU side of the MMU (or something that look like this). At this stage the paging management for the GPU will be almost impracticable from within a driver to cooperate efficiently with the core operating system, not counting the brainfuck crap in case there are not developed by closely related peoples. This don't automatically say that GPU driver will cease to exist for some graphic aspect, but the GPUCPU part will end up into the kernel for the most critical aspects. It's easy to see why on Linux, access to the GPU from a proprietary driver is really not an option for the future (even if the current issue is only about DMA sharing data between devices).