1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems

Facebook RSS Twitter Twitter Google Plus

Phoronix Test Suite

OpenBenchmarking Benchmarking Platform
Phoromatic Test Orchestration

Intel & The Shortcomings Of Gallium3D


Published on 13 April 2010 10:17 AM EDT
Written by Michael Larabel in Intel
Add A Comment

While Gallium3D is viewed as the future of the 3D Linux graphics driver architecture, it's been in development for a long time and still doesn't have a solid following. In particular, Intel is still missing from the Gallium3D party.

Gallium3D originally had an Intel 915 driver written by Tungsten Graphics at the time as an example, but that driver has faded away. There have been efforts to write Gallium3D drivers for Intel 945 and 965 hardware too, but those efforts were lead by Tungsten Graphics / VMware and have yet to really come to fruition (although the i965 Gallium3D driver is living in master).

We have previously reported that Intel has been holding off on an Intel Gallium3D driver due to the initial investment involved in bringing a Gallium3D driver up to the same speed and feature parity as their classic Mesa 3D driver. This is no overnight effort and up until recently even the "R300g" Gallium3D driver that supports ATI Radeon R300/400/500 hardware was really not in a good position, but after many months of work, it's now out-performing the classic Mesa Radeon driver, but is still a ways behind the proprietary Catalyst Linux driver.

Jesse Barnes has pretty much reiterated this no-Gallium3D Intel position on Gallium3D over the Mesa mailing list:

Sorry, couldn't resist this flamebait.

My message wrt Gallium has been consistent at least, and I know the other Intel developers agree with me (though they may have additional issues with some of the interfaces specifically).

Moving to Gallium would be a huge effort for us. We've invested a lot into the current drivers, stabilizing them, adding features, and generally supporting them. If we moved to Gallium, much of that effort would be thrown away as with any large rewrite, leaving users in a situation where the driver that worked was unsupported and the one that was supported didn't work very well (at least for quite some time).

Currently, the benefits of Gallium are outweighed by this consideration, at least in my opinion. However, Dave has been poking us a bit about using LLVM for a sw vertex shader implementation on 945, which Gallium would make much easier aiui, so who knows things may change in the future. I still worry about delivering a high quality and supported driver to our users though.

I don't think this consideration is political, to me it's very practical.

I really wish the move to Gallium had been a more gradual evolution of the current code base, since it would have allowed working drivers to take advantage of the new infrastructure over time (though not having worked with Gallium I won't pretend to suggest how this might have worked best). As it stands we have a lot of duplication in the 915, 965 and r300 drivers between classic Mesa and Gallium, which seems a shame.

Jesse Barnes, Intel Open Source Technology Center

While "leaving users in a situation where the driver that worked was unsupported and the one that was supported didn't work very well" is understandable, it was just last year when rewriting other portions of their driver had completely killed the Atom netbook experience. This was with the initially very-buggy code for DRI2, the Graphics Execution Manager, and UXA (UMA Acceleration Architecture) that wound up in most of the H1'09 Linux distributions where the performance was seriously regressed and there were stability problems, among other issues, for many Intel customers.

Their quick move from user-space to kernel-based mode-setting is still being felt. Intel was quick to kill off user-space mode-setting support that even with the soon-to-be-released Ubuntu 10.04 LTS they are using the old xf86-video-intel 2.9 DDX driver since anything newer lacks UMS support, but with some hardware the kernel mode-setting support is still not working up to their standards.

Even with Gallium3D requiring an initial upfront investment, over the classic Mesa driver it provides support for more graphics APIs (like OpenVG and currently OpenGL ES 1.1/2.0), more generic performance optimization work, and a variety of other ongoing enhancements such as to do with LLVM. Gallium3D drivers are also more portable and cross-platform friendly.

Getting back on track, resulting from Jesse's mailing list message, a discussion has ensued on the Mesa mailing list about Gallium3D, its shortcomings, and perhaps where things could have been better in retrospect.

Michel Dänzer immediately pointed out that had Intel been on the Gallium3D bandwagon from the beginning things could have been much smoother for them, David Airlie saying Gallium3D is not yet mature enough to actually ship a driver, a proposal from a Nouveau developer for Intel to open-source their Windows driver as it could be easier to port that to Gallium3D, and regrets from Tungsten/VMware employees over not having a strong "reference" Gallium3D driver upfront based on new ATI or Intel hardware that they could use to showcase the strengths and design of the Gallium3D driver architecture.

There's also discussions surrounding some potential problems with the Gallium3D design itself that may not allow it to live up to ideal performance levels. Read the mailing list thread though for all of the details and what has been discussed since last night.

For reference we do have benchmarks comparing Radeon's classic Mesa driver to their Gallium3D driver, a comparison of the Radeon Gallium3D driver to the Catalyst driver, classic Mesa vs. Catalyst with R700 hardware, and benchmarks of Nouveau's Gallium3D driver. We also have more tests on the way.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux News
  1. Radeon & AMDGPU DRM Fixes Queue Up For Linux 4.2
  2. KDE Applications 15.04.3 Fixes Bugs
  3. Benchmarks Of 54 Different Intel/AMD Linux Systems
  4. Linux 4.2 Bringing Support For ARCv2, HS38 CPU Cores
  5. Libdrm 2.4.62 Is An Important Update For Open-Source GPU Drivers
  6. The State of Unity 3D Game Engine, Editor On Linux
  7. ZFS On Linux Brings Linux 4.1 Support, Fixes
  8. Old Net Burst Tests, Ubuntu Phone & Assembly x86 Were Popular Topics Last Month
  9. Qt 5.5 Officially Released
  10. Global Shortcuts In KDE Plasma Under Wayland
Latest Articles & Reviews
  1. How KDE VDG Is Trying To Make Open-Source Software Beautiful
  2. Attempting To Try Out BCache On The Linux 4.1 Kernel
  3. CompuLab's Fitlet Is A Very Tiny, Fanless, Linux PC With AMD A10 Micro
  4. AMD A10-7870K Godavari: RadeonSI Gallium3D vs. Catalyst Linux Drivers
Most Viewed News This Week
  1. Kubuntu 15.10 Could Be The End Of The Road
  2. KDBUS Won't Be Pushed Until The Linux 4.3 Kernel
  3. The State & Complications Of Porting The Unity Editor To Linux
  4. The Staging Pull For Linux 4.2: "Big, Really Big"
  5. Latest Rumor Pegs Microsoft Wanting To Buy AMD
  6. SteamOS "Brewmaster" Is Valve's New Debian 8.1 Based Version
  7. Exciting Features Merged So Far For The Linux 4.2 Kernel
  8. ARM Posts Pictures Of AMD's New Development Board