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.org

Intel & The Shortcomings Of Gallium3D

Intel

Published on 13 April 2010 10:17 AM EDT
Written by Michael Larabel in Intel
29 Comments

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 Hardware Reviews
  1. A Walkthrough Of The New 32 System Open-Source Linux Benchmarking Test Farm
  2. Habey MITX-6771: Mini-ITX Board With Quad-Core J1900 Bay Trail
  3. OCZ Vector 150 SSD On Linux
  4. Noctua i4 CPU Cooler: Great For Cooling High-End LGA-2011v3 CPUs
Latest Linux Articles
  1. AMD Kaveri: Open-Source Radeon Gallium3D vs. Catalyst 14.12 Omega Driver
  2. 12-Way AMD Catalyst 14.12 vs. NVIDIA 346 Series Linux GPU Comparison
  3. AMD Catalyst 14.12 Omega Driver Brings Mixed Results For Linux Users
  4. 6-Way Winter 2014 Linux Distribution Comparison
Latest Linux News
  1. Intel Skylake Audio Support For Linux 3.19
  2. After 10+ Years, NetworkManager Reaches v1.0
  3. VDPAU Updated To v0.9
  4. An Open Hardware Random Number Generator Proposed
  5. LLVM 3.6 Will Be Branched Next Month
  6. Opera Browser Puts Out Linux Updates For The Holidays
  7. GNOME Shell 3.15.3 Adds Support For High-Contrast Themes
  8. Linux 3.19: ThinkPad Muting Redone, New Dell Backlight Support, Acer Is Banging
  9. KVM Drops Support For IA64 While Adding Various x86 Improvements
  10. GCC 4.8.4 Officially Released
Latest Forum Discussions
  1. XLennart: A Game For Systemd Haters With Nothing Better To Do
  2. Need some hand holding with upgrading xserver
  3. Debian init discussion in Phoenix Wright format
  4. The New SuperTuxKart Looks Better, But Can Cause GPU/Driver Problems
  5. FPS capped on Linux (AMD fglrx drivers)
  6. Are there an app using HSA ?
  7. Bench specific mount point
  8. Tool for measuring FPS in games