The Different Gallium3D Drivers Available
Cell: This is one of the original Gallium3D hardware drivers and was written by Tungsten Graphics (since acquired by VMware) for IBM's Cell micro-processor. The Cell driver rasterizers across the SPUs in a parallel tile-based manner. OpenGL should work on this driver, but it hasn't been touched since February of 2009. Even back in 2008 and 2009 the Cell driver received mostly compatibility fixes to make it compatible with the latest Gallium3D core, with the last major work on the Cell driver happening around 2007.
Failover: While "Failover" lives in the Gallium3D drivers tree, it's not an actual hardware driver itself. Failover just acts as a module to select between an actual hardware driver and the software-based Softpipe driver. If the hardware/driver can't support a particular operation, this is the module that will instead pass it to the software driver for rendering.
Galahad: The Galahad driver, like Failover, isn't a hardware driver itself. It's basically a "sanity-checking layer" so that driver developers can spot potential problems within the Gallium3D stack.
i915: The i915 Gallium3D driver is what's been worked on lately by Google for Chromium OS. This driver originally was worked on by VMware (Tungsten Graphics at the time) as another sample hardware driver when they were also doing the IBM Cell driver. Sans the recent Google activity, i915g usually just sees random commits from time-to-time with no major traction since Intel doesn't officially back this driver but rather their classic (non-Gallium3D) Mesa driver. The i915 driver is designed to support the Intel 915/945/G33/Q33/Q35/Pineview integrated graphics processors.
i965: The i965 Gallium3D driver is another creation by Tungsten Graphics / VMware. Since the Mesa developers at VMware don't actively work on this code and Intel officially isn't interested in Gallium3D, it receives less work than the i915 driver. There were commits to the i965g driver back in January that provided a few updates thanks to pulling in some updated code from the classic i965 driver, but it hasn't received two much significant work since last year.
This Intel 965 Gallium3D driver is said to support the 946GZ, 965G, 965Q, 965GM 965GME, GM45, G41, B43, Q45, and G45 IGPs. There's also entries for the Ironlake desktop and mobile chips, but at last check, that graphics adapter found on the Clarkdale/Arrandale CPUs wasn't well supported at all within this driver's code-base.
Identity: The Gallium3D Identity driver is similar to Galahad and Failover in that they aren't "real" drivers. The Identity driver doesn't do any transformations to the Gallium3D calls and it's just meant to serve as a basis for transforming/debugging other drivers like Trace and Rbug. It's a VMware creation from 2009.
LLVMpipe: This is the ideal Gallium3D driver to use if interested in CPU-based software acceleration. LLVMpipe is basically the equivalent of Mesa's software rasterizer that just renders everything using the CPU and system memory. Besides being a fall-back in cases where no hardware driver may be available, it's also useful for driver developers in debugging situations. What makes LLVMpipe better than the other alternative, Softpipe, is that it leverages the Low-Level Virtual Machine (LLVM) for optimizing the process and being able to take better advantage of modern processors.
While better than Softpipe, LLVMpipe at the moment is still quite slow and really isn't too useful unless you have an extremely fast CPU. This driver also doesn't support modern compositing window managers at this time like Mutter and Compiz. See the Phoronix LLVMpipe articles for more information. Hopefully in the not too distant future this will be the default software fallback in cases where a GPU driver is unavailable (it's already been defaulted to in Fedora). The LLVMpipe driver sees work from time-to-time.
Noop: The Noop driver is a Red Hat creation from last year that's meant to be the "No Operation" driver. This driver is a fake DRI software driver that performs no operations besides allocating the Gallium structure and buffer. This is another "fake" driver meant to be used for profiling core Gallium3D/Mesa without having pipe driver overhead. This small driver has only received a few commits this calendar year.
Nouveau: This is the common Nouveau Gallium3D driver code for supporting the community reverse-engineered 3D support for NVIDIA GeForce/Quadro graphics hardware.
NV50: The Nouveau NV50 driver is what provides the Gallium3D support for the GeForce 8, GeForce 9, GeForce 100, GeForce 200, and GeForce 300 graphics card series. Of the different Nouveau drivers, it's for these generations of hardware that generally sees the most work by the community developers.
NVC0: The NVC0 driver is for the NVIDIA "Fermi" hardware, which currently includes the GeForce 400 and GeForce 500 series. This newest Nouveau Gallium3D component is still a work in progress, but it's functioning and running some OpenGL games. Besides the Gallium3D side still being developed, there's still better NVIDIA GeForce 400/500 Fermi support needed in the kernel DRM driver for supporting power management and other features on this very latest architecture. The current mainline code also still requires loading the external FUC firmware in order to enable accelerated support, but with the Linux 3.1 kernel, the Nouveau DRM driver should be capable of generating its own firmware.
NVFX: The Nouveau NVFX driver doesn't receive as much support as it had in the past by the independent developers. The Nouveau driver on the GeForce 6 series at Phoronix haven't even successfully worked with OpenGL in a number of months, perhaps even a year, after regressing hard. The NVFX driver is meant to support the GeForce 5/FX, GeForce 6, and GeForce 7 series hardware.
R300: The "R300g" driver is likely to be the most mature Gallium3D hardware driver currently in existence. This driver supports the R300 through R500 series, which includes products from the Radeon 9700 series through the ATI Radeon X1000 series. The R300g driver began as a Google Summer of Code project several years ago and since then has received much attention and has well surpassed the capabilities of the ATI R300 classic driver.
R600: The ATI/AMD R600 driver is the Gallium3D driver to support the R600 (Radeon HD 2000) series and newer, which is where the R300 driver left off due to architectural differences. The generations currently supported include the Radeon HD 2000, 3000, 4000, 5000, and 6000/6900 series. The current AMD Fusion APUs are also supported by this driver. Using the latest version of Mesa, the R600 Gallium3D driver should just as stable (or more stable) than the R600 classic driver, faster (for most OpenGL workloads), and more feature-rich. It's also for the R600 Gallium3D driver where there is accelerated video playback developing. This driver, along with R300, continues to receive a great deal of work by numerous parties.
Rbug: The Rbug component is another special driver like Identity, Galahad, and Noop. The Rbug driver provides remote debugger capabilities for the pipe driver. Included elsewhere in the Mesa tree is a small remote debugging application that's used in conjunction with the Rbug driver. The Rbug pipe driver can be used either inside a state tracker or target.
Softpipe: This is the most basic Gallium3D driver used for software acceleration and basic driver debugging. In terms of end-users, I'd heavily recommend using LLVMpipe instead of Softpipe as it's much faster, albeit both solutions are slow compared to a real GPU hardware driver.
SVGA: The SVGA driver is VMware's virtual Gallium3D driver for use in conjunction with their proprietary virtualization products. The SVGA Gallium3D driver can be run inside a guest operating system being virtualized by VMware and then accelerated on the host's hardware. The SVGA driver is quite good although it's in the process of being overhauled.
Trace: The Trace driver is another debugging option for developers. The Trace debugger pipe driver will create XML-based trace dumps that can be XSL formatted in a web-browser. Like Rbug, it too can be hooked inside a target or state tracker.
8 Comments
