1) Nvidia and AMD both do per-game optimizations in the drivers themselves. Though my understand is that Nvidia has more resources dedicated to this. They will send 1 or 2 people to the studios of AAA game devs nearer release to help the company optimize their game plus to add "hacks" into their own drivers to work around inefficiencies in those games.
If they opened sourced their drivers, that work would be made free to AMD and other drivers.
2) "Benchmark Cheating". Graphics Drivers do lots of optimizations depending on the specific application. I'd wager that this includes popular benchmark apps.
3) Patent lawsuits. There are a massive number of patents around the graphics word. Obscuring how a driver works probably helps protect them somewhat from potential patent litigation.
Here's a quote from another hn user robert_foss from the discussion on the Apple / Imagination Technologies thread.
'In the GPU space it is impossible to not infringe on the IP of other vendors.
In fact it is the major reason GPU vendors give for not having an open source driver. I have spoken to the CTO (Jem Davies) of ARM about the GPU drivers and open sourcing them more than once. And every time I've gotten the reply: "No, we can't, it opens us up to IP infringement suits."'
Both AMD's and Intel's OSS drivers are 'clean room' separate codebases to their internal closed drivers. It may be that they are specifically avoiding some features/rewriting possibly infringing code in these cases.
As far as I know, we have yet to have an open driver to get the same performance as their closed windows ones in all cases. There may be reasons behind that.
> Nvidia and AMD both do per-game optimizations in the drivers themselves
It's worse than that. Most DirectX code is incorrect to begin with, and GPU manufacturers tailor their drivers to make stuff that should not be valid run for specific games. hence the "the way it's meant to be played" and the nonsense of newer drivers bringing 20-30% performance increase for recent games.
You can easily ship a "plain vanilla" open source GPU driver separate from the proprietary "game optimizer" code, because the former doesn't block the availability of the latter.
And if you suspect a GPU driver is cheating on a benchmark, or you have grounds to sue for IP/patent infringement, you don't need to have the source code for that. Any sufficiently motivated organization can verify that right now by disassembling the binary driver.
The real meaning behind patent infringement concerns is that the source code contains clues to the "secret sauce" that the binaries don't make readily accessible. So publishing the source is publishing the restricted IP. Whereas their license to use the IP allows publishing of the binaries.
There's no way to avoid giving away clues to "secret sauce" when releasing a driver, and keeping the source code closed doesn't change that. I don't see how the degree of accessibility is relevant.
The fact is that clues to IP can't be removed when compiling the source to binary form, because implementation details can't be hidden. So the status quo is that they are already public. Granted, it takes more skill and patience to analyze the clues in this form, but any competent hacker can do it. And the absence of names and comments in the binary makes the job harder, but doesn't actually remove the significant clues.
And while it's true that these drivers might be using licensed code, which restricts publication of its source code, this seems like a poor excuse for keeping all the code proprietary. The existence of licensed code doesn't block releasing the rest of the code. And I'm willing to bet there is an army of volunteers out there that is more than happy to write a clean room replacement for the licensed parts, if the vendor can't do it, given the opportunity.
Those guesses are likely right on the mark. A company like NVIDIA uses excuses like this to avoid change, and after years of trying them, believes them.
The sad fact is that these are entirely unreasonable claims, and that it would be wholely in NVIDIA's favor to open their drivers.
1) If they release the bulk of their driver work under a BSD-like licence, they can still keep those patches secret.
It would even be to NVIDIA's advantage to do this, since game devs would be able to work with the original driver codebase, and know what to expect from it; and therefore write better code in the first place.
2) Same as #1
3) Intel has open drivers. AMDGPU is open. This is a sad excuse, not a valid reason.
> They will send 1 or 2 people to the studios of AAA game devs nearer release to help the company optimize their game plus to add "hacks" into their own drivers to work around inefficiencies in those games.
Depending on the nature of the hacks, there's not necessarily anything wrong with that. It's common for drivers, even Open Source drivers, to detect common patterns of API misuse that would otherwise hurt performance, and transform them into patterns that achieve the same effect more efficiently. But that only applies if you can detect the inefficiency by pattern, rather than by application name. If the driver does the latter, then yeah, it'd be hard to Open Source that.
> But that only applies if you can detect the inefficiency by pattern, rather than by application name.
Nvidia "experience" driver management software "optimizes" how games run by finding the .exe name of the game. Change the .exe filename, and your performance drops. So they are doing exactly what you suggested they might be doing.
That's because drivers do not look for API "patterns of inefficiencies". The optimizations are either in global settings like resource distribution (found through extensive profiling so impossible to do automatically in the driver) or optimized shaders (again, guided by profiling and not even possible at the app level since the game cannot ship with the native shader code). If you ever wrote C/C++ code with the performance requirements you know that different programs will run fastest with different compiler options, drivers provide these optimal options for the different games and if you change the name of the game the options are likely to become non-optimal.
- Driver source code may contain info that would give hints to upcoming or in-development products and innovations from the company that they'd prefer to keep secret.
- Drivers may have features disabled in software, but not in hardware - if you could compile your own, it would effectively overrule this.
- Open-sourcing drivers may make it easier for the competition to "copy" innovations and features
GPU drivers are not just simple pieces of code that are used to access hardware. They contain very fast implementations of extremely complex libraries, and optimizing compilers for complex programming languages. Just to give you an idea of the ballpark, the nVidia GPU drivers are a more complex system with more code than the entire Linux kernel.
As the performance of this system is absolutely critical, a large part of the value proposition of a GPU is its driver package. Since nVidia clearly leads the pack in the quality of their drivers, they have no intention of opening them up.
If you compare the whole driver stack, KMD+UMDs (OGL,DX,CUDA,Vulkan) to just the kernel part of Linux, sounds about right. The KMD alone is definitely smaller than Linux kernel.
Just open-sourcing and upstreaming the KMD would resolve the biggest pain-point in linux. The "very fast implementations of extremely complex libraries, and optimizing compilers for complex programming languages" can be separate.
In addition to the reasons others have mentioned: cross-licensing of code, such that the vendor doesn't directly have the rights to release it without rewriting portions of it.
Why care whether the driver is open source? Just consider the driver as part of the black box that is the product. The vendor will provide you with a blob of binary code that you can invoke. This binary code can be the same on Windows and Linux. Of course, a driver has to interact with the kernel, but the required glue logic can be maintained separately.
Edit: Of course, the driver should be run inside a controlled environment (e.g. a sandbox), but this arguably holds for all drivers, even open-source ones.
This is what AMDGPU-PRO attempts to do. It's still incompatible and buggy.
When a driver is closed source, the only people who can fix bugs, keep the driver updated, patch security holes, implement new APIs like Wayland, Vulkan, OpenGL extensions, etc. are the employees of the company who owns the driver.
Was it important for AMD to make old ATI cards work with newer versions of Xorg? With Wayland? With Windows? AMD certainly didn't think so. Since the existing driver was proprietary, those that did care had to implement another driver from scratch!
Open source drivers exist for practically every video card, and have for decades. The problem is that they all suck except those that were supported by the manufacturer in the first place.
I can't believe I am reading garbage like this on a forum called "Hacker News." Richard Stallman literally started the Free Software movement because the driver to the Xerox 9700 laster printer was closed source. Please read Steven Levy's Hackers and Sam William's Free as in Freedom. Asking "why care whether the driver is open source" to me as a hacker is like asking "why care whether you are a slave?"
I think their point is that you can say the same about closed hardware. And since you're already putting a black-box hardware component into the system (with its own black-box firmware, as well), how much more harmful is it to have a closed driver?
I totally agree. But open-source drivers running in a sandbox are even more secure than proprietary ones in a sandbox, which is the essence of the defense in depth.
I think open-source drivers are a net good, but proprietary drivers are a pain because of ABI instability more than anything else. Linux could improve on this. I get why they don't, and I don't have an opinion positive or negative on their stance because I don't use desktop Linux anymore--but this is not just a driver-vendor thing.
No it's an ecosystem thing. Linux distro upstreams are source compatible but not binary compatible. You can compile any combination of applications and libraries together, but you cannot expect a compiled binary from a completely different environment to work in your environment. It's just a coincidence that major linux distributions are similar enough to USUALLY be binary compatible with eachother. What an open graphics driver would allow, for example, is the use of a busybox and ulibc ultra-compact linux environment to be a tiny control node to command the much more powerful GPU. That just can't happen right now with binary only drivers that expect to live on a very specific binary stack. If you change the stack, you lose everything.
So I've read your post a few times, and I'm pretty confused. What exactly does this have to do with my post? What does uclibc have to do with kernel ABIs?
That...has very, very little, perhaps nothing, to do with your prior post. It is also silly, because proprietary code exists and is necessary to use Linux in the way people want to use it. A static ABI is not stupid if it enables users to do the things they want to do with a tool--namely, use nVidia hardware effectively and optimally. That the Linux kernel doesn't support that is not a feature when their userbase is a rounding error of all nVidia users and are in no position to be making demands.
tl;dr ABIs are an implementation detail, what people want are stable drivers. And if Linux did provide a stable ABI, then people would create midlayers, which silos everyone and encourages them to improve their midlayers instead of improving the base, and the improved base is what makes Linux so good in the first place. Using the base is necessary for community interaction.
I understand the concern--but, fundamentally, the problem here is that Linux isn't big enough on the desktop, and won't be big enough on the desktop, to dictate terms in the way that the "community interaction" folks want to.
You compromise when you're the little guy, or you lose. (And I don't think the Linux maintainers really care about the desktop all that much, so I understand the decision and it's totally okay in my book. That's why I went back to a Mac and Windows on the desktop. Different tools for different jobs.)
But maybe if we let people write midlayers, in time those would converge to the best midlayer design, then they would coalesce to a single library since the midlayer is not the product and open sourcing your dependecies is good business, and finally it can enter upstream.
Drivers contain details about how the GPU (or whatever) hardware is structured and works internally. Some companies want to keep that info proprietary.
Tell that to Broadcom, Intel, Marvell, Qualcomm Atheros, and Realtek. All of them released open source Linux drivers for their wireless network products and they're still doing good business. So I don't buy this line of argument.
That might be true, but the general point is that most drivers in the Linux kernel don't need blobs, and they are in many cases written by manufacturers of the hardware.
Competing manufacturers have not suffered as a result of releasing free Linux drivers, and arguably are profiting from it.
A big (but not singular) answer to that question is that proprietary drivers are what allows companies like NVidia to price-discriminate, by selling the same hardware but disabling features for lower priced models.
> There are no legitimate reasons for them to be, only sad excuses.
Are you an IP lawyer? I'm not, but I work with people who are, and they would disagree with you rather strongly with regard to certain cases and certain fields. It's pretty presumptuous to tell people what legal risks they should expose themselves to (and to forestall the tired and obvious, it's great that Intel thinks that they're OK and can open their stuff--but I sure get why others aren't so cavalier).
Did I say that excuse was ill founded, or that it has no basis or support in fact? No. It is, indeed, a valid excuse. That doesn't mean it's a good excuse. Who is going to sue then over IP? AMD? Intel? NVIDIA is touted to have the best drivers. By that logic, NVIDIA should sue Intel, after all, Intel got into graphics much later, so they must be violating NVIDIA's IP, right?
When it is said that "NVIDIA cannot open their source because of potential litigation", that is an excuse, not a reason. That is a potential difficulty of change, not a reason to be stagnant.
I understand how those at NVIDIA might think they need to stay proprietary. There are several valid excuses they can use to support that claim, but each excuse I have heard does not hold up in reality: NVIDIA certainly can and should change.
The current state of patent law is that the only way you can be sure not to infringe on it is to never build anything, ever. In that environment, I can actually sympathize with "I'm breaking the law, but I don't want to get in trouble".
What if the laws are dumb and dangerously arbitrary? Like, say, patent laws. To be fair, it's not so much "laws" as "things people can sue you over", but that distinction doesn't become relevant until after the lawsuit and large amounts of money down the drain. And then they disappear without recouping your costs, because they're a goddamn shell company.
It is a sad excuse, but only because we live in a sad reality with massively broken patent laws.
That would be true, if the laws weren't harmful on their own. 20 year patents are way too long, and software patents are ridiculous. Only 5 more years before you can write a linked list with multiple traversal orders without licensing it from the patent holder! https://www.google.com/patents/US7028023
If it's a "dealing pot" sort of infringement (e.g. against patents that shouldn't exist, but do), then it's a legitimate reason to hide their tracks. If it's a "robbing banks" level of infringement, then it's not.
At the very least, vendors should provide something like a data sheet with all the register information a developer would need to write their own driver. There's no need to give away the recipe to the special sauce.
Max I ever saw was around 100 simultaneous connections on projects that jumped up on the page. Not sure I would consider that a _lot_ for any reasonable hardware.
Aren't drivers inherently a loss-leader so that a company can sell hardware? Why not always open up the drivers?