

Why aren't device drivers typically open source? - landryraccoon

Just the question in the title. I&#x27;m curious because most hardware manufacturers don&#x27;t open source their device drivers (Nvidia is a good example) but they give the drivers away for free - they make money by selling the hardware. It seems like it would be in their interest to open source drivers since users could adapt their hardware to operating systems &#x2F; flavors the manufacturers don&#x27;t have the resources to support, increasing market size. Users could even find and fix bugs with the drivers, and submit patches back to the manufacturer. Does anyone have insight into this?
======
jfasi
Since you mention Nvidia, here's little case study about graphics card
drivers. My direct experience is with Qualcomm's Adreno driver on Android
circa 2.3, so it's kinda niche and a little dated, but I understand it roughly
holds for the rest of the graphics world. Naturally, these points don't
necessarily apply to all devices that require drivers, but they serve to
illustrate things somewhat.

As background, a typical graphics stack looks like this, from bottom to top.
All components are designed, implemented, and maintained by the GPU
manufacturer:

1\. Graphics card is presented to the kernel through some mechanism. On
Android/ARM, this was as a device memory mapped into a hardware-specified set
of addresses. This layer provides the computational component.

2\. A kernel driver whose function is to accept GPU code and funnel it down to
the device through the appropriate mechanism. This layer provides the
input/output mechanisms necessary to communicate with the device, and contains
knowledge about the communication protocol the card follows.

3\. An OpenGL driver. This is basically a compiler than accepts sequences of
OpenGL calls, and translates them down to the hardware-level implementation.
Most knowledge of the computational details of the GPU's architecture lives
here.

Of these layers, only the kernel driver, number 2, was open source when I
worked with it. This is because it links into the Linux kernel, and so needs
to be GPL (Not certain about this, please feel free to correct me.) In any
case, this component does not contain much or any "secret sauce," so it's
fairly safe to share.

The rest of the components, however, are closed source. The reasons for this
are:

1\. The GPU hardware's architectural design is a trade secret. Even the
instruction set architecture is closed source. The reason for this is that
much of the competitive advantage a GPU manufacturer might enjoy stems from
the speed (and power efficiency) of its GPU architecture. Publishing the
architecture would basically provide the GPU maker's competitors access to
valuable intellectual property: a lot of research goes into designing a good
ISA, and you could probably tell a lot about how the device functions if you
had access to the ISA spec.

2\. Following this rationale, keeping the ISA secret allows the manufacturer a
great deal of flexibility. They have no reason to worry about backwards
compatibility because they own the product, so they can do whatever they want
with it: add instructions, remove instructions, change calling conventions,
whatever.

For comparison, one of Intel's (many) strengths is its robust backward
compatibility for its ISA. The basic outline of Intel's x86 ISA have been
unchanged for decades, and when they do roll out changes, they're additive
rather than subtractive, and they take _years_ to fully roll out. Secrecy
presumably allows GPU makers to turn things around as quickly as they feel
necessary by freeing them of this backward compatibility constraint.

3\. I'm less confident about this point, but I presume there are some tricks
they do in implementing the OpenGL library driver. Wherever there are multiple
competing implementations of something, you're guaranteed to have tricks the
various implementors are proud of.

tl;dr: Keeping drivers secret allow manufacturers to obfuscate their
architectural implementation, protecting their intellectual property and
affording them a measure of flexibility when they want to make changes to it.

~~~
cbhl
Another component here is that it might not even be _their_ intellectual
property per se; my understanding (from what I've heard from friends who've
worked at graphics card companies) is that some of the hardware / OpenGL
driver may contain IP that the graphics company has licensed and isn't even
allowed to release as F/OSS if they wanted to.

IIRC, certain "Intel Integrated Graphics" variants suffered from this problem,
and to this day lack good 3D F/OSS drivers.

------
tmzt
I think this is a great question.

The reasons given for graphics drivers not being open are quite reasonable and
I will exclude that quality from that discussion.

Many other devices are so basic that the driver is little more than a
variation of the example code in the SDK (I'm considering Windows drivers
here). Yet the manufacturers guard the source code for their version of the
driver as they would if there was something really valuable in there.

In some software the driver is just a simple layer between the application and
the hardware, most of the implementation is in the application and the driver
could be opened and still maintain compatibility with the application.

At the same time users that are interested could be utilities or applications
that improve what the user could do with the hardware.

------
zachlatta
I believe there was a recent discussion about this on HN, I couldn't find a
link though. If I recall correctly, it's due to drivers containing trade
secrets and being very specific to proprietary hardware.

------
drill_sarge
Because there are parts of the driver (from 3rd party providers too) which
contain patented stuff. So they don't want to expose this. S3TC is one famous
example. Thats the only reason (apart from some company specific politics).

------
john_whelan
[http://hackaday.com/2013/10/22/usb-implementers-forum-
says-n...](http://hackaday.com/2013/10/22/usb-implementers-forum-says-no-to-
open-source/) \- This should be a good artical

