Intel & The Shortcomings Of Gallium3D

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.