A free and open-source graphics device driver is a software stack which controls computer-graphics hardware and supports graphics-rendering application programming interfaces (APIs) and is released under a free and open-source software license. Graphics device drivers are written for specific hardware to work within a specific operating system kernel and to support a range of APIs used by applications to access the graphics hardware. They may also control output to the display if the display driver is part of the graphics hardware. Most free and open-source graphics device drivers are developed by the Mesa project. The driver is made up of a compiler, a rendering API, and software which manages access to the graphics hardware.
Drivers without freely (and legally) available source code are commonly known as binary drivers. Binary drivers used in the context of operating systems that are prone to ongoing development and change (such as Linux) create problems for end users and package maintainers. These problems, which affect system stability, security and performance, are the main reason for the independent development of free and open-source drivers. When no technical documentation is available, an understanding of the underlying hardware is often gained by clean-room reverse engineering. Based on this understanding, device drivers may be written and legally published under any software license.
In rare cases, a manufacturer's driver source code is available on the Internet without a free license. This means that the code can be studied and altered for personal use, but the altered (and usually the original) source code cannot be freely distributed. Solutions to bugs in the driver cannot be easily shared in the form of modified versions of the driver. Therefore, the utility of such drivers is significantly reduced in comparison to free and open-source drivers.
Problems with proprietary drivers
Software developer's view
There are objections to binary-only drivers based on copyright, security, reliability and development concerns. As part of a wider campaign against binary blobs, OpenBSD lead developer Theo de Raadt said that with a binary driver there is "no way to fix it when it breaks (and it will break)"; when a product which relies on binary drivers is declared to be end-of-life by the manufacturer, it is effectively "broken forever." The project has also stated that binary drivers "hide bugs and workarounds for bugs", an observation which has been somewhat vindicated by flaws found in binary drivers (including an exploitable bug in Nvidia's 3D drivers discovered in October 2006 by Rapid7). It is speculated that the bug has existed since 2004; Nvidia has denied this, asserting that the issue was only communicated to them in July 2006 and the 2004 bug was a bug in X.Org (not in Nvidia's driver).
Binary drivers often do not work with current versions of open-source software, and rarely support development snapshots of open-source software; it is usually not directly possible for a developer to use Nvidia's or ATI's proprietary drivers with a development snapshot of an X server or a development snapshot of the Linux kernel. Features like kernel mode-setting cannot be added to binary drivers by anyone but the vendors, which prevents their inclusion if the vendor lacks capacity or interest.
In the Linux kernel development community, Linus Torvalds has made strong statements on the issue of binary-only modules: "I refuse to even consider tying my hands over some binary-only module ... I want people to know that when they use binary-only modules, it's their problem". Another kernel developer, Greg Kroah-Hartman, has said that a binary-only kernel module does not comply with the kernel's license (the GNU General Public License); it "just violates the GPL due to fun things like derivative works and linking and other stuff." Writer and computer scientist Peter Gutmann has expressed concern that the digital rights management scheme in Microsoft's Windows Vista operating system may limit the availability of the documentation required to write open drivers, since it "requires that the operational details of the device be kept confidential."
In the case of binary drivers, there are objections due to free software philosophy, software quality and security concerns.Linux Weekly News, Aug 14, 2006: X.org, distributors, and proprietary modules In 2006, Greg Kroah-Hartman concluded that:
The Linux kernel has never maintained a stable in-kernel application binary interface. There are also concerns that proprietary drivers may contain backdoors, like the one found in Samsung Galaxy-series modem drivers.
Hardware developer's view
When applications such as a 3D game engine or a 3D computer graphics software shunt calculations from the CPU to the GPU, they usually use a special-purpose API like OpenGL or Direct3D and do not address the hardware directly. Because all translation (from API calls to GPU opcodes) is done by the device driver, it contains specialized knowledge and is an object of optimization. Due to the history of the rigidity of proprietary driver development there has been a recent surge in the number of community-backed device drivers for desktop and mobile GPUs. Free and Open Hardware organizations like FOSSi, LowRISC, and others, would also benefit from the development of an open graphical hardware standard. This would then provide computer manufacturers, hobbyists, and the like with a complete, royalty-free platform with which to develop computing hardware and related devices.
The desktop computer market was long dominated by PC hardware using the x86/x86-64 instruction set and GPUs available for the PC. With three major competitors (Nvidia, AMD and Intel). The main competing factor was the price of hardware and raw performance in 3D computer games, which is greatly affected by the efficient translation of API calls into GPU opcodes. The display driver and the video decoder are inherent parts of the graphics card: hardware designed to assist in the calculations necessary for the decoding of video streams. As the market for PC hardware has dwindled, it seems unlikely that new competitors will enter this market and it is unclear how much more knowledge one company could gain by seeing the source code of other companies' drivers.
The mobile sector presents a different situation. The functional blocks (the application-specific integrated circuit display driver, 2D and 3D acceleration and video decoding and encoding) are separate semiconductor intellectual property (SIP) blocks on the chip, since hardware devices vary substantially; some portable media players require a display driver that accelerates video decoding, but does not require 3D acceleration. The development goal is not only raw 3D performance, but system integration, power consumption and 2D capabilities. There is also an approach which abandons the traditional method (Vsync) of updating the display and makes better use of sample and hold technology to lower power consumption.
During the second quarter of 2013 79.3% of smartphones sold worldwide were running a version of Android, and the Linux kernel dominates smartphones. Hardware developers have an incentive to deliver Linux drivers for their hardware but, due to competition, no incentive to make these drivers free and open-source. Additional problems are the Android-specific augmentations to the Linux kernel which have not been accepted in mainline, such as the Atomic Display Framework (ADF). ADF is a feature of 3.10 AOSP kernels which provides a dma-buf-centric framework between Android's hwcomposer HAL and the kernel driver. ADF significantly overlaps with the DRM-KMS framework. ADF has not been accepted into mainline, but a different set of solutions addressing the same problems (known as atomic mode setting) is under development. Projects such as libhybris harness Android device drivers to run on Linux platforms other than Android.
Software architecture
Free and open-source drivers are primarily developed on and for Linux by Linux kernel developers, third-party programming enthusiasts and employees of companies such as Advanced Micro Devices. Each driver has five parts: A Linux kernel component DRM A Linux kernel component KMS driver (the display controller driver) A libDRM user-space component (a wrapper library for DRM system calls, which should only be used by Mesa 3D) A Mesa 3D user-space component. This component is hardware-specific; it is executed on the CPU and translates OpenGL commands, for example, into machine code for the GPU. Because the device driver is split, marshalling is possible. Mesa 3D is the only free and open-source implementation of OpenGL, OpenGL ES, OpenVG, GLX, EGL and OpenCL. In July 2014, most of the components conformed to Gallium3D specifications. A fully functional State Tracker for Direct3D version 9 is written in C, and an unmaintained tracker for Direct3D versions 10 and 11 is written in C++. Wine has Direct3D version 9. Another Wine component translates Direct3D calls into OpenGL calls, working with OpenGL. Device Dependent X (DDX), another 2D graphics device driver for X.Org Server
The DRM is kernel-specific. A VESA driver is generally available for any operating system. The VESA driver supports most graphics cards without acceleration and at display resolutions limited to a set programmed in the Video BIOS by the manufacturer.
History The Linux graphics stack has evolved, detoured by the X Window System core protocol.
Free and open-source drivers ATI and AMD Radeon
AMD's proprietary driver, AMD Catalyst for their Radeon, is available for Microsoft Windows and Linux (formerly fglrx). A current version can be downloaded from AMD's site, and some Linux distributions contain it in their repositories. It is in the process of being replaced with an AMDGPU-PRO hybrid driver combining the open-source kernel, X and Mesa multimedia drivers with closed-source OpenGL, OpenCL and Vulkan drivers derived from Catalyst.
The FOSS drivers for ATI-AMD GPUs are being developed under the name Radeon (xf86-video-ati or xserver-xorg-video-radeon). They still must load proprietary microcode into the GPU to enable hardware acceleration.Details of Debian package firmware-linux-nonfree in Stable Debian.org
Radeon 3D code is split into six drivers, according to GPU technology: the radeon, r200 and r300 classic drivers and r300g, r600g and radeonsi Gallium3D drivers: Radeon supports the R100 series. R200 supports the R200 series. R300g supports pre-unified shader model microarchitectures: R300, R400 and R500. R600g supports all TeraScale (VLIW5/4)-based GPUs: R600, R700, HD 5000 (Evergreen) and HD 6000 (Northern Islands). Radeonsi supports all Graphics Core Next-based GPUs: HD 7000, HD 8000 and Rx 200 (Southern Islands, Sea Islands and Volcanic Islands).
An up-to-date feature matrix is available, and there is support for Video Coding Engine and Unified Video Decoder. The free and open-source Radeon graphics device drivers are not reverse-engineered, but are based on documentation released by AMD without the requirement to sign a non-disclosure agreement (NDA). Documentation began to be gradually released in 2007.
In addition to providing the necessary documentation, AMD employees contribute code to support their hardware and features.
All components of the Radeon graphics device driver are developed by core contributors and interested parties worldwide. In 2011, the r300g outperformed Catalyst in some cases.
AMDGPU
At the 2014 Game Developers Conference, AMD announced that they were exploring a strategy change to re-base the user-space part of Catalyst on a free and open-source DRM kernel module instead of their proprietary kernel blob.