Free and open-source graphics device driver

Data and instructions are sent to the GPU for processing. The rendered results are stored in a piece of memory called the framebuffer. The content of the framebuffer is subsequently scanned out by the display controller and sent to the screen.

A free and open-source graphics device driver is a software stack that controls computer graphics hardware and supports graphics rendering APIs and is released under a Free and open source software license. Graphics device drivers are written for specific hardware to work within the context of 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 via the Mesa project.

Such a software stack comprises some compiler, some implementation of some rendering API, and finally some software, that manages access to the graphics hardware.

All hardware developers provide device drivers for their products over a range of operating systems. But some developers of graphics hardware provide no free and open-source drivers for their hardware and they provide little or no technical documentation to support independent development of free and open-source device drivers for their products. The free and open source device drivers available for hardware with support for independent driver development are generally of much higher quality in terms of completeness, stability, security and performance than drivers for hardware that lack such support.

Drivers without freely (and thus legally) available source code are commonly referred to 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 to both end-users and package maintainers. These problems affect system stability, overall system security, and performance and 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 chosen software license.

There are rare and special cases, where manufacturers' driver source code is publicly available in the Internet, but not under a free license. This means that the code can be studied and altered for personal use, but the altered (and usually even the original) source code cannot be freely distributed, so solutions to bugs in the driver cannot be shared, significantly reducing the utility of such drivers in comparison to completely free and open-source drivers.

Problems with binary drivers

From a software developer's perspective

Illustration of the Linux graphics stack

There are a number of objections to binary-only drivers. There are philosophical and ethical objections, with some feeling that drivers distributed without source code are against the beliefs of the free software movement. There are very pragmatic objections regarding copyright, security, reliability and development concerns. As part of a wider campaign against binary blobs, OpenBSD lead developer Theo de Raadt has pointed out that with a binary driver there is "no way to fix it when it breaks (and it will break)" and that once 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 asserted that binary drivers "hide bugs and workarounds for bugs," a comment that has been somewhat vindicated by flaws found in binary drivers, including in October 2006 an exploitable bug in Nvidia's 3D drivers discovered by Rapid7. It is speculated that this bug has existed since 2004, although Nvidia have denied this, asserting that the issue was only communicated to them in July 2006 and that the 2004 bug was a bug in X.Org, not in Nvidia's driver. Another problem with binary drivers is that they often do not work with current versions of open source software, and almost never support development snapshots of open source software - e.g. 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. Furthermore, 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, asserting: "I refuse to even consider tying my hands over some binary-only module", and continuing: "I want people to know that when they use binary-only modules, it's THEIR problem". Another kernel developer, Greg Kroah-Hartman, has commented 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 concerns 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 as it "requires that the operational details of the device be kept confidential."

In the case of binary drivers there are also objections due to free software philosophy, software quality and security concerns. There are also concerns that the redistribution of closed source Linux kernel modules may be illegal.

By choice, the Linux kernel has never maintained a stable in-kernel Application binary interface.

There are also some concerns that proprietary drivers may even contain backdoors, like one that was found in Samsung Galaxy series modem drivers.

From a hardware developer's perspective

In the future libGL-fglrx-glx could use the libDRM of the radeon open-source driver instead of the proprietary binary blob, since most of the investment is in the user-space driver.

Application-specific integrated circuitry, integrated circuitry, and microprocessors, when designed with the primary goal of efficiency, with regards to power consumption, silicon usage, and the actual acceleration of the calculations required to rasterise 3D wire-frame models, are actually pretty simple and straightforward.

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 (see also Cell (microprocessor)). Because all translation from API calls to actual GPU opcodes is done by the device driver, it will contain a considerable amount of specialized knowledge and be the constant object of optimization. This takes time and involves significant financial investment. Thus leakage of device driver source code, whether published under a free license or not, can give competitors an advantage — especially newcomers to the business of graphic acceleration, who would gain a considerable amount of know-how without bearing the costs of developing that knowledge.

The desktop computer market was for a long time dominated by PC hardware using the x86/x86-64 instruction set, and by GPUs available for the PC. With only 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 is an inherent part of the graphics card, as is the video decoder, hardware designed to assist in the calculations necessary for the decoding of video streams. As the market for PC hardware has been dwindling, it seems highly unlikely that new competitors will enter this market. Thus it is unclear how much more know-how one company could gain by seeing the source code of the drivers of the other companies.

The mobile sector however, presents a different situation:

• The functional blocks (i.e. the display driver ASIC, the 3D acceleration ASIC, the 2D acceleration ASIC, Video decoding and Video encoding ASIC) are separate SIP (SIP) blocks, since the hardware devices are very different from each other. Some portable media player do require a display driver and gains from Video decoding acceleration, but do not require any sort of 3D acceleration, etc.
• The development goal is not only raw 3D performance, but also system integration, power consumption and 2D capabilities. There is also an approach to abandon the traditional method (Vsync) of updating the display and make better use of the possibilities that came with the sample and hold-technology to significantly lower power consumption.
• There are more competitors on the market and there are newcomers (e.g. while Imagination has been around since before 2000, Vivante entered this market in 2005. Ingenic experimented with some own SIP solutions for graphics.)
• Usually CPU and the GPU are integrated on one die and also share the main memory, which is considerably slower than the distinct graphics memory in graphics cards for Desktop PCs. Yet, this is cheaper, smaller and does benefit power consumption because there are fewer components needed.

The growing mobile market, the unsatisfied requirements of mobile devices and the advantages that can be gained by the development of new techniques leaves much more room for the existing competition and for new competitors entering the market. Thus the SIP and the software supporting it (the device drivers and maybe even the software infrastructure for these device drivers, i.e. the entire graphics stack) can be considered more prone to discretion and a quick launch to market.

When looking at the fact that during the second quarter of 2013, 79.3% of smartphones sold worldwide were running some version of Android, it is clear that the Linux kernel is dominant on smartphones. Thus hardware developers have a huge incentive to deliver excellent Linux drivers for their hardware, but due to the competition, no incentive what-so-ever to make these driver free and open-source. An additional problem are the Android-specific augmentations to the Linux kernel, which have not been accepted into mainline, e.g. the Atomic Display Framework. ADF is a feature found in 3.10 AOSP kernels that provides dma-buf centric plumbing framework between Android's hwcomposer HAL and kernel driver. ADF significantly overlaps with DRM/KMS framework. Concluding ADF has not been accepted into mainline, but instead a different set of solutions addressing the same problems is being worked on called Atomic Mode Setting.

Projects like libhybris try to combine the power of the existent Linux android drivers with different platforms than Android. Additionally there are ongoing efforts to write free and open-source drivers by independent developers.

Cue list

• Device drivers are the abstraction layer between software concepts and hardware circuitry
• provide a standard interface to peripherals, hiding all the ugly details of how the circuitry solves things, from the programmer
• almost any system operation eventually maps to some physical device
• the kernel embeds device drivers for every peripheral present in the computer system
• device drivers have seven times the bug rate of other kernel code
• should provide mechanism, not policy

Performance comparison

glxgears is not well-suited for benchmarks.

A source for real-world testing is Phoronix. They routinely run benchmarks comparing involving the free driver as well. E.g.

• from 19 March 2011 http://www.phoronix.com/scan.php?page=news_item&px=OTIzMg
• from 31 March 2013 http://www.phoronix.com/scan.php?page=article&item=nouveau_2639_flip&num=1
• a comparison from 29 April 2013 between FOSS and proprietary drivers: Phoronix
• a comparison from 27 October 2013 between proprietary drivers on Windows 8.1 and Linux: Ubuntu Linux Gaming Performance Mostly On Par With Windows 8.1
• a comparison from 25 January 2014 between FOSS drivers on Linux only: http://www.phoronix.com/scan.php?page=article&item=linux_2014_opengpu&num=1
• a comparison from 27 January 2014 between proprietary drivers on Linux only: http://www.phoronix.com/scan.php?page=article&item=linux_gpus_2014start&num=1
• a comparison from 19 March 2014 between Ubuntu with the Free and open-source graphics device driver distributed as part of Mesa 3D clearly outperforms Mac OS X 10.9.2 when playing OpenGL-based Xonotic on a MacBook Air 2013.

It is uncommon for computer game magazines to report any benchmark testing on Linux. Benchmarks on Phoronix are limited in scope, primarily test games using Quake Engine derivatives.

Software architecture

Mesa /DRI and Gallium3D have different driver models. Both share a lot of free and open-source code

An example matrix for implementing the Gallium3D driver model. Through the introduction of the Gallium3D Tracker Interface and the Gallium3D WinSys Interface, only 18 instead of 36 modules are required. Each WinSys module can work with each Gallium3D device driver module and with each State Tracker module.

The free and open-source drivers are primarily developed on Linux and for Linux. They have been under constant development by the Linux kernel developers, by 3rd party programming enthusiasts and also by employees of companies such as e.g.AMD. Each driver is composed out of five parts:

1. Linux kernel component DRM
2. Linux kernel component KMS driver: basically the device driver for the display controller
3. user-space component libDRM: a wrapper library for the system calls of the DRM, should only be used by Mesa 3D
4. user-space component in Mesa 3D: this component is highly hardware specific, is being executed on the CPU and does the translation of e.g. OpenGL commands into machine code for the GPU;
   because of the split nature of the device driver, marshalling is possible;
   Mesa 3D is the only available free and open-source implementation of OpenGL, OpenGL ES, OpenVG, GLX, EGL and OpenCL
   as of July 2014 most of these components are written conforming to the Gallium3D-specifications;
   there is a fully functional State Tracker for Direct3D version 9 written in C and an un-maintained one for Direct3D versions 10 and 11 written in C++.
   Annotation: Wine contains an implementation of the Direct3D version 9. Another Wine component used to translate Direct3D calls into OpenGL calls and it works on top of the OpenGL implementation in Mesa 3D. When the Gallium3D State Tracker for D3D9 is available, a patched version of Wine could be used, adapting it to use the D3D9 State Tracker, and thus avoiding this conversion step. Note that these patches weren't accepted by mainstream Wine as of April 2014. The Gallium3D State Tracker for D3D9, device drivers have a direct interface to the Direct3D 9 API, increasing the performance by a factor of two and more.
   • all drivers in Mesa 3D are as of July 2014 limited to OpenGL version 3.3. For other APIs, see the Mesa 3D article
5. Device Dependent X (DDX), an additional special and distinct 2D graphics device driver extra for X.Org Server (Which is going to be replaced by Glamor)

The DRM is kernel specific and has to be ported to FreeBSD, OpenBSD, and some other kernels.

In general, there's a vesa driver for any operating system available. The vesa driver supports most graphics cards without acceleration and with display resolutions limited to a set of resolutions programmed in the video BIOS by the manufacturer. See e.g. /Documentation/fb

History

The Linux graphics stack have been prone to a long evolution over the years, with some unnecessary detours due to the X Window System core protocol. Understanding this history should help comprehend the current design and its late arrival.

• 

  2D drivers inside of the X server

• 

  Indirect rendering over GLX, using Utah GLX

• 

  Direct Rendering Infrastructure and framebuffer

• 

  Finally all access goes through the Direct Rendering Manager

• 

  In Linux kernel 3.12 render nodes were merged and the KMS was split off. Wayland implements direct rendering over EGL

Free and open-source drivers

In general, the VESA driver supports most graphics cards without acceleration and with display resolutions limited to a set of resolutions programmed in the video BIOS by the manufacturer.

Also see: Kernel Documentation/fb or the Phoronix Test Suite

ATI/AMD

/drivers/gpu/drm/radeon

See also: List of AMD graphics processing units and List of AMD Accelerated Processing Unit microprocessors

Radeon hardware support: three kernel-mode drivers: amdgpu, radeon and fgrlx.ko and two user-mode drivers: Mesa 3D and Radeon Software (former AMD Catalyst).

AMD's proprietary driver AMD Catalyst for their Radeon is only available for Microsoft Windows and Linux (formerly name fglrx). A current version can be downloaded from the Internet and some Linux distributions contain it in their repositories.
The FOSS drivers for ATI/AMD GPUs are all being developed under the name radeon (xf86-video-ati or xserver-xorg-video-radeon). The drivers still have to load proprietary microcode into the GPU to enable hardware acceleration.

radeon 3D code is split into six parts: the radeon, r200 and r300 classic-style drivers and r300g, r600g, radeonsi Gallium3D-style drivers:

• the radeon supports the R100 series
• the r200 supports R200 series
• the r300g supports pre-Unified shader model microarchitectures: R300, R400, and R500
• the r600g supports all TeraScale (VLIW5/4)-based GPUs: R600, R700, HD 5000 ("Evergreen") and HD 6000 ("Northern Islands")
• the radeonsi supports all Graphics Core Next-based GPUs: HD 7000, HD 8000 and Rx 200 ("Southern Islands" or "Sea Islands")

An up-to-date feature matrix is available at: radeon feature matrix; there is e.g. support for Video Coding Engine and Unified Video Decoder.

The free and open-source "Radeon" graphics device drivers are not reverse engineered, but based on documentation released by AMD without the requirement to sign any non-disclosure agreement (NDA). Documentation has been released gradually beginning in 2007.

This is in strong contrast to AMD's main competitor in the graphics field Nvidia, which does offer its own proprietary driver similar to AMD Catalyst, but does not provide any support or assistance to any free graphics initiatives.

Beside providing the necessary documentation, AMD employees also actively contribute code to support their hardware and features of it. At GDC 2014, AMD announced 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.

All parts and components of the free and open-source "Radeon" graphics device driver are prone to a constant development by the core contributors and interested people worldwide. The performance optimizations were successful already in 2011, when the r300g was able to outperform Catalyst in some select cases. Current benchmarks can be found in this article in the Performance comparison section.

/drivers/gpu/drm/amd/amdgpu

The initial release of the new amdgpu-stack has been announced on the dri-devel mailing list in April 2015. Development and testing of the driver happens on GCN 1.1 graphics cards, but the driver is enabled only for GCN 1.2 graphics cards, as GCN 1.0 and 1.1 graphics cards are supported by the radeon driver. Regarding the naming of the involved microarchitectures consult Graphics Core Next.

Development

Documentation about the GCN-hardware is available from AMD without the requirement to sign some NDA, with development mainly driven by AMD employees. The entire development should flow together into Alex Deucher's git-tree: http://cgit.freedesktop.org/~agd5f/linux/log/?h=amdgpu David Airlie is the overall maintainer for the entire DRM-tree. He sends his pull request directly to Torvalds.

Documented maintainers are best found in https://www.kernel.org/doc/linux/MAINTAINERS

History amdgpu

amdkfd was mainlined into Linux kernel 3.19 and amdgpu into 4.2. The source code as released with Linux kernel can be viewed through cgit as follows:

• https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/gpu/drm/amd?id=refs/tags/v3.19
• https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/gpu/drm/amd?id=refs/tags/v4.0
• https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/gpu/drm/amd?id=refs/tags/v4.1
• https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/gpu/drm/amd?id=refs/tags/v4.2
• https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/gpu/drm/amd?id=refs/tags/v4.3
• https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/gpu/drm/amd?id=refs/tags/v4.4
• https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/gpu/drm/amd?id=refs/tags/v4.5-rc1
• https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/drivers/gpu/drm/amd/?id=v4.5&id2=v4.4 Linux kernel 4.5 (released March 14, 2016) brought support for AMD PowerPlay

The diffs with more or less insightful commentaries should be obtainable on the Linux kernel mailing list (LKML) and forks thereof e.g. https://lwn.net/Articles/653318/. Documentation of the software remains scarce and is scattered over the web in various blog posts…

There is a separate libdrm called libdrm-amdgpu, which has been included since libdrm 2.4.63.

Nvidia

See also: List of Nvidia graphics processing units and nouveau

A screenshot of REnouveau, which is a program that collects data for most of nouveau's reverse engineering work

Nvidia's proprietary driver Nvidia GeForce driver for their GeForce is available for Windows XP x86/x86-64 and later, Linux x86/x86-64/ARMv7-A, OS X 10.5 and later, Solaris x86/x86-64 and FreeBSD x86/x86-64. A current version can be downloaded from the Internet and some Linux distributions contain it in their repositories. Nvidia GeForce driver 331.13 BETA from 4 October 2013 supports the EGL interface enabling support for Wayland in conjunction with this driver.

Nvidia's free and open-source driver is called nv. This driver is very limited and supports only 2D acceleration, and Matthew Garrett, Dirk Hohndel and others claim its source-code is obfuscated. In March 2010 Nvidia has decided to deprecate nv and not add support for Fermi or later GPU, nor add support for DisplayPort to this driver.

In December 2009 Nvidia publicly announced they would not provide any support or assistance to any free graphics initiatives. On 23 September 2013 Nvidia publicly announced, that they would release some documentation about their GPUs.

Nouveau is based almost entirely on information gained through reverse engineering. This project aims to produce 3D acceleration for X.Org/Wayland utilizing Gallium3D. On March 26, 2012, the DRM component of Nouveau was marked as stable and promoted from the staging area of the Linux kernel. Nouveau supports: Tesla- and earlier, Fermi-, Kepler-, and Maxwell-based GPUs. As of 31 January 2014, Nvidia employee Alexandre Courbo committed an extensive patch set which adds initial support for the GK20A (Tegra K1) to nouveau. In June 2014, Codethink reported to run Wayland-based Weston compositor with Linux kernel 3.15, making use of EGL and a "100% open-source graphics driver stack" on a Tegra K1.

An up-to-date feature matrix is available at Nouveau Driver Feature Matrix

Current benchmarks can be found in this article in the Performance comparison section. As of July 2014 Nouveau has not been able to outperform Nvidia GeForce driver due to missing "re-clocking" support.

tegra-re is the name of the project, that is working in reverse-engineering nVidia's VLIW-based Tegra series of GPUs, that pre-date "Tegra K1".

Nvidia distributes proprietary device drivers for Tegra through OEMs and as part of its "Linux for Tegra" (formerly "L4T") development kit. As of April 2012, due to different "business needs" from that of their GeForce line of graphics cards, Nvidia and one of their Embedded Partners, Avionic Design GmbH from Germany, are also working on submitting free and open-source drivers for Tegra upstream to the mainline Linux kernel. Nvidia co-founder & CEO laid out the Tegra processor roadmap using Ubuntu Unity in GPU Technology Conference 2013.

History of nouveau

• …
• https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/drivers/gpu/drm/nouveau/?id=v3.1&id2=v3.0
• …
• https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/drivers/gpu/drm/nouveau/?id=v4.5&id2=v4.4

Intel

See also: List of Intel graphics processing units, Intel GMA § Linux, and Intel HD and Iris Graphics

Intel has a long history of producing or commissioning open source drivers for its graphics chips, with the exception of their PowerVR-based chips.

The 2D X.Org driver is called xf86-video-intel. The kernel modesetting driver in the Linux kernel does not use the video BIOS for switching video modes; as some BIOSes include only a limited range of modes, this provides more reliable access to those supported by Intel video cards.

Unlike the radeon and nouveau drivers, Intel does not intend to utilize the Gallium3D framework for its graphics drivers. Intel has also recently put work into optimizing their free Linux drivers to have closer performance to their Windows counterparts, especially on Sandy Bridge and newer hardware where various performance optimizations have now allowed the free Intel driver to be able to outperform their proprietary Windows drivers at certain tasks. Some of these performance enhancements can also benefit users of older hardware.

Support for Intel's LLC (Last Level Cache, L4-Cache, Crystalwell, Iris Pro) was added in Linux kernel 3.12

Intel has 20 to 30 full-time Linux graphics developers.

Matrox

Matrox develops and manufactures these products:

• Matrox Mystique
• Matrox Parhelia
• Matrox G200
• Matrox G400
• Matrox G550

Matrox provides free and open source drivers for all their chipsets older than the G550; chipsets newer than the G550 are only supported by a closed source driver.

S3 Graphics

S3 Graphics develops these products:

• S3 Trio
• S3 ViRGE
• S3 Savage
• S3 Chrome supported by openChrome

ARM

See also: Mali

ARM Holdings is a fabless semiconductor company which licenses SIP cores. They are known for the licensing the ARM instruction set and CPUs based upon it but they also develop and license the Mali series of GPUs. On January 21, 2012, Phoronix reported that Luc Verhaegen was driving a reverse-engineering attempt aimed at the ARM Holdings Mali series of GPUs, specifically the Mali-200 and Mali-400 versions. The reverse-engineering project was presented at FOSDEM, February 4, 2012. On February 2, 2013, Verhaegen demonstrated Quake III Arena in timedemo mode, running on top of the Lima driver.

ARM has shown no intention of providing support for their graphics acceleration hardware licensed under some free and open-source license. But in December 2015 and April 2016 ARM employees did send patches for the Linux kernel to support at least their display controller SIP blocks "ARM HDLCD display controller" and Mali DP500, DP550 and DP650.

Imagination Technologies

See also: PowerVR

Imagination Technologies is a fabless semiconductor company which licenses SIP cores. They are known for the licensing the MIPS instruction set and CPUs based upon it but probably even more for developing and licensing the PowerVR series of GPUs. Intel has manufactured a number of PowerVR based GPUs. PowerVR GPUs are widely used in mobile SoCs. Imagination Technologies do not provide a FOSS driver nor any documentation for their products. Due to its vast appearance in embedded devices, the Free Software Foundation has put reverse-engineering of the PowerVR driver on a high-priority project list.

PowerVR reverse engineering project

Vivante

See also: Vivante GCxxxx

Vivante is a fabless semiconductor company which licenses SIP cores. They develop the GCxxxx series of GPUs. There is a proprietary and closed source Linux driver from Vivante consisting of a kernel space and a user space part. The kernel component is available as open source (GPL) however the user space components which consist of the GLES(2) implementations and a HAL library are not. These, however, contain the bulk of the driver logic.

Wladimir J. van der Laan found out and documented the state bits, command stream, and shader ISA by studying how these blobs work. He studied these by examining and manipulating command stream dumps. Based upon this documentation the Gallium3D driver etna_viv is being written. Wladimir's work was inspired by libv. Due to the simplicity of the vivante hardware, etna_viv has surpassed what libv has achieved quicker than similar projects. The project has produced a functional-but-unoptimized Gallium3D LLVM driver. The etna_viv driver has performed better than vivante's own proprietary code in some benchmarks. It supports Vivante's product line of GC400 Series, GC800 Series and the GC1000 Series.

• etna_viv https://github.com/etnaviv/etna_viv
• BLTsville http://graphics.github.io/bltsville/ is an open 2D API, usable for the 2D graphics chip Vivante GC320, included in Texas Instruments OMAP4 or as software only.
• Support in the form of a DRM driver appeared in Linux kernel 4.5: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/drivers/gpu/drm/etnaviv?id=v4.5&id2=v4.4

Qualcomm

See also: Adreno

Qualcomm develops the Adreno (former ATI Imageon) GPU series, and include it exclusively as part of their Snapdragon (system on chip). In 2012, Phoronix and Slashdot reported that Rob Clark was working on reverse-engineering drivers for the Adreno GPU series. Clark wrote in a referenced blog post that he is doing the project in his spare time, and that the Qualcomm platform was his only viable target for working on open 3D graphics since his employers (Texas Instruments and Linaro) were affiliated with the Imagination PowerVR and ARM Mali cores which would otherwise have been his primary targets, and that he already had working command streams for 2D support, and that 3D commands seemed to have the same characteristics. The driver code was published on Gitorious under the name freedreno. It has since been moved to Mesa. In 2012, a working shader assembler was completed and demonstration versions were developed for texture mapping and phong shading using the reverse-engineered shader compiler. At FOSDEM, February 2, 2013, Clark demonstrated Freedreno running desktop compositing, the XBMC media player and Quake III Arena.

As of August 2013, the kernel component of freedreno, called MSM driver, was accepted into mainline, and is available in Linux kernel 3.12 and later.

In July 2014, the DDX driver gained support for server managed file descriptors, requiring X.Org Server version 1.16 and above.

In January 2016, the Mesa Gallium3D-style driver gained support for Adreno 430.

• freedreno: http://freedreno.github.io/ https://archive.fosdem.org/2013/schedule/event/freedreno/
  • https://github.com/freedreno/freedreno/wiki/Video-Acceleration

Broadcom

The Mesa-driver for VideoCore4 is termed VC4 and has been written from scratch by Eric Anholt, employed by Broadcom.

See also: VideoCore

Broadcom develops and designs the VideoCore GPU series as part of their SoCs. Due to the fact that it is used by the Raspberry Pi there has been strong interest in a FOSS driver for VideoCore. and on October 24, 2012 the Raspberry Pi Foundation, in co-operation with Broadcom, announced they open sourced, "all the ARM (CPU) code that drives the GPU". Unfortunately, the code released at that date reflected the very minimum needed to make an open-source announcement. The open-source components allowed message-passing between the ARM CPU and VideoCore, but offered little insight into Videocore and little further programmability. This was because the Videocore GPU runs an RTOS that handles the real processing; all of the actual video acceleration is done using this RTOS firmware coded for its proprietary GPU, and this firmware wasn't open sourced at that date. Further, as there was neither a toolchain available that could target this proprietary GPU, nor was its Instruction set documented, so no possible advantage could be taken in case if the firmware source code was made available. The project videocoreiv tried to document the VideoCore GPUs. Based upon this documentation a driver could have been written.

But on February 28, 2014, on the day of the second anniversary of the Raspberry PI Broadcom, together with the Raspberry PI foundation, announced the release of full documentation for the VideoCore IV graphics core, and a complete source release of the graphics stack under a 3-clause BSD license

The free licensed 3D graphics code was committed to mesa on 2014-08-09, and first appeared on 10.3 release.

• Official Broadcom documentation: http://www.broadcom.com/docs/support/videocore/VideoCoreIV-AG100-R.pdf
• VC4 DRM made it into Linux kernel 4.4: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/drivers/gpu/drm/vc4?id=v4.4&id2=v4.3
• support for 3D acceleration made it into 4.5: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/drivers/gpu/drm/vc4?id=v4.5&id2=v4.4 (merge)

Other vendors

SiS and VIA have both shown limited interest and communication regarding open source drivers; however, both have released source code which has later been integrated into X.Org by FOSS developers. In July 2008, VIA opened up documentation for their products to improve its image within the Linux and open-source communities. Although, so far VIA has failed to work with the open source community to provide documentation and a working DRM driver, leaving expectations for supporting the Linux operating system unfulfilled. On January 6, 2011 it was announced that VIA was no longer interested in supporting free graphics initiatives.

DisplayLink have announced an open source project called libdlo with the goal of bringing support for their USB graphics technology to Linux and other platforms. The code is available under the LGPL license. It has not yet been integrated into an X.Org driver. DisplayLink graphics support is available through the kernel udlfb driver (with fbdev) in mainline, and udl/drm driver, which as of March 2012 is only available in the drm-next tree.

Often other non-hardware related vendors may also lend a hand to free graphics initiatives. Red Hat has some employees working full-time on several free and open source software projects, such as two full-time employees working on the free software radeon (David Airlie and Jérôme Glisse) and one full-time employee working on the free software nouveau graphic drivers. In addition, the Fedora Project runs a "Fedora Graphics Test Week" event before the launch of their new Linux distribution versions in order to provide rigorous testing to free graphics drivers. Other companies that have provided development or support include Novell and VMware.

Open hardware projects

Project VGA assembled PCB

Open Graphics Project assembled PCB

Project VGA aims to create a low budget, open source, VGA compatible video card. All information to create one is available, but at present there seems to be no development. Some data:

• PCI bus interface (32 bit, 33/66 MHz, 3,3/5V compatible)
• Xilinx Spartan-3 S400 FPGA (aiming for ~100 MHz)
• 16 MB SDRAM (aiming for ~166 MHz)
• Onboard programmer with USB interface
• VGA connector

The Open Graphics Project is another aim at creating an open hardware GPU. The Open Graphics Device v1 features dual DVI-I outputs and 100-pin IDC connector. On September 2010, the first 25 OGD1 boards were made available for grant application and purchase ($750).

The Milkymist system-on-chip, targeted at embedded graphics instead of desktop computers, supports a VGA output, a limited vertex shader and a 2D texturing unit.

Although these projects may exist, if they use FPGAs, they tend to have partially or completely non-free and closed-source toolchains. There are relatively few FPGAs with completely open-source toolchains.

See also

• Intel GMA
• Direct Rendering Infrastructure (DRI)
• High Priority Free Software Projects
• 3D computer graphics
• Open Graphics Project

External links

• Linux graphics drivers from Intel
• NVIDIA's Unix drivers portal page
• Project VGA
• Direct3D 9 state tracker on Gallium3D
• d3d1x: add new Direct3D 10/11 COM state tracker for Gallium
• Status updates for three graphics drivers (Nouveau, amdgpu and Etnaviv) LWN.net 2015