The aim of this project is to solve an issue that often is the subject of discussions and disputes within the
Free Software community against the main GPU’s vendors because there is very little information
available about 3D/OpenGL graphics support and performance.
This situation leads users to install proprietary graphics card drivers because of the limited support available in current free software drivers such as X.Org (which includes Direct Rendering Infrastructure (DRI) support for a variety of 3D graphics hardware but often doesn’t support every feature or doesn’t offer performance as fast as that of the proprietary drivers) or Mesa.
The actual state of the Open Source Graphic Processor project is visible from the infographic below.
This project (as the apertus one) has the potential of a revolutionary birth, in the silicon’s scenario for the reasons I’m going to explain, but it also put itself in a difficult path, in which many other projects have failed due to a lack of participation by the community, does it mean that the Free Software community doeasn’t care about that ones who use this kind of technologies?
Here somebody has tried to answer this and other questions about this kind of efforts:
If we look to the Linus Torvalds http://lwn.net/1999/0211/a/lt-binary.html, the doubt has its right to grow on our minds.
But let’s come back to non-developers readers and explain a bit, with words and infographics, what we are taliing about.
What should these drivers do?
A free and open-source graphics device driver is software that controls computer graphics hardware and supports
graphics rendering APIs, distributed at no cost with openly shared source code.
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.
In order to be usable every graphic card or GPU is provided by developers with device drivers over a range of
operating systems. In the cases in which no free and open-source drivers are provied for a hardware there is no
technical documentation to support independent development of free and open-source device drivers and this causes
the controversies to raise in the Free Softwae community.
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.
Beyond the 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”
in effect, in October 2006 an exploitable bug in Nvidia’s 3D drivers was discovered. 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.
Hence we have to notice that 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.
The Linux Kernel Developers Community
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 (unless he works for the vendor) 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.
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. 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, and linking and other stuff.”
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.
This is the most common method of writing the Open Source Drivers for a GPU graphics card, the main web pages where
you can find information about this drivers, and comparisons on each board’s performance are free3D and Phoronix.
There are rare and special cases, where manufacturers’ driver source code is openly available in the Internet,
but not under a free license. This means that the code can be studied and altered for personal usage, but the altered
(and usually even the original) source code cannot be freely distributed, so problem solutions cannot be shared,
significantly reducing the utility of such drivers in comparison to completely free and open-source drivers.
Intel maintain only free and open-source driver for Linux.
Application-specific integrated circuitry / microprocessors designed and suitable to efficiently, when looking at power consumption and silicon, accelerate the calculations required by the rasterisation of 3D wire-frame models, is actually pretty simple and straight forward.
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. All the translation from API calls to actual GPU opcodes, is done by the device driver, hence the device driver contains a considerable amount of know-how, and is the constant object of optimization.
The market for PC has been dwindling for the last couple of years. It seems highly unlikely new competitors will enter this market, and it is hard to say, how much more know-how one company would gain, by having a glance at the source code of the drivers of the other company.
An antonym is going to raise thanks to the mobile sector as explained in this interesting article.
Let’s say that 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 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.
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.