Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
A New Model
This all changes with the new Gallium 3D architecture that has been recently merged into Mesa. Typically, when you design a driver API, you create an abstract form of the device and require all concrete devices to provide this abstract interface. You can think of a driver as a piece of code that makes some specific piece of hardware emulate a simple, abstract, virtual device.
A hard disk controller, for example, is a block device and so is expected to support operations like “store this block at this location” and “read the block from this location.” Individual drivers will provide these functions by issuing SCSI or IDE commands down a PCI bus (for example). Graphics drivers are no different. When cards were designed for accelerating a fixed-function API, it made sense to require the drivers to provide something that looked like a simplified version of OpenGL or Direct3D.
Gallium uses the same idea, but a much more modern idea of what the hardware looks like. Rather than viewing the hardware as a specialized graphics unit, it views it as a coprocessor designed for running programs written in Tungsten Graphics Shader Infrastructure (TGSI), an abstract binary format for shader programs.
The virtual device that a Gallium driver has to implement still has some internal state, but this state more accurately reflects the state that modern hardware does track. It is not tied to a specific graphics API. This means that you can plug different state trackers in on top of it to implement different APIs.
One of the first things to be implemented was OpenGL 2.1, using Mesa. This cleans up the interface between Mesa and the DRI drivers a lot. Where previously you had a complex set of interfaces between Mesa and each driver, now you have a complex interface between Mesa and the Gallium state tracker and a simple interface between the Gallium state tracker and the driver.
This is convenient for driver developers, because it means that they need to know a lot less about how OpenGL works and can write much simpler drivers. This isn't particularly interesting to users, however. Much more exciting is the fact that it makes it possible to plug in other state trackers, for other APIs, much more easily.
Recently, Gallium gained state trackers for the OpenGL ES 1.1 and 2.0 APIs. These are the fixed-function and shader-based versions of the OpenGL-derived APIs commonly found in handheld devices. There is also one for OpenVG, a 2D vector graphics, used for things like Flash and SVG acceleration.
Adding support for OpenGL 3.1 on top of Gallium is likely to prove a lot easier than adding it on top of the existing drivers. Another project likely to benefit from this is WINE. Currently, the WINE implementation of Direct3D transforms Direct3D commands into OpenGL. This is not always trivial. While both APIs implement the same functionality, they provide different and not always compatible abstractions. Implementing a Direct3D state tracker on top of Gallium would make it possible to run any Direct3D software without the overhead of going via OpenGL.
At the other end of the stack, Gallium also includes a relatively clean set of interfaces to the kernel and host windowing system. These are responsible for things like memory management and context creation. The aim is to make it possible to reuse the majority of the driver code everywhere—on Linux, BSDs, and even Windows.
This last part is very important. One of the common arguments given for not implementing drivers for open source operating systems is cost. If a given OS has a 1 percent market share, then the return on investment for supporting it is very small. If, however, the cost of porting a driver to that operating system is very low, then the return becomes much more attractive.
Readers who have been paying attention to the industry recall that Tungsten Graphics, the company behind the Gallium architecture, was bought by VMWare a little while ago. It may seem strange that a company that writes graphics drivers would be a tempting acquisition target for a company that produces a hypervisor. Looking at the Gallium architecture, it is a little more obvious.
The abstraction between the layers in the driver means that it is relatively easy to add a skeleton driver that directs commands to another VM. As long as the guest running the 3D apps and the guest controlling the hardware are supported by Gallium, the applications can be accelerated. Of course, it's not just VMWare that benefits from this; Christopher Smowton at Cambridge implemented a prototype doing exactly this on top of Xen this year.