Mesa Devs Discuss Potentially Dropping Non-Gallium Drivers Or Forking Code For Gallium

Written by Michael Larabel in Mesa on 4 December 2019 at 07:56 AM EST. 47 Comments
MESA
Longtime open-source AMD graphics driver developer Marek Olšák has kicked off a discussion over the possibility in the not too distant future of either dropping non-Gallium3D drivers from Mesa (and moving them off to a maintenance branch or the like) or forking some of Mesa's existing code to allow it to be better optimized for Gallium3D use-cases. Due to raised concerns, other possibilities are also being expressed like simply moving ahead with optimizing the Mesa code-base for Gallium3D at a cost of potentially hitting dead code more often with the classic drivers.

As it stands now, the only relevant non-Gallium3D driver in the Mesa code-base is Intel i965. While that's currently the default Intel driver, for Broadwell "Gen8" graphics and newer they will be transitioning to their new Iris Gallium3D driver by default expected to happen for Mesa 20.0. The i965 driver will still be around for Haswell and older generations to come -- either within mainline Mesa or some maintenance branch. As part of this new Mesa discussion was a hypothetical comment about creating a new Intel Gallium3D driver for Haswell and older, but that's extremely unlikely to happen and was just brought up as a matter of being thorough. There aren't the extra resources available to create an Intel Gallium3D driver for aging Haswell and older hardware plus that it would likely take around a year to develop and even longer before reaching performance parity to i965.

But even with all modern hardware being backed by Gallium3D drivers, upstream Mesa developers aren't comfortable with dropping non-Gallium3D support quite yet nor with the idea of forking some of Mesa's OpenGL code so that it could be better optimized for Gallium3D. Forking/duplicating that code for Gallium3D would lead to a greater maintenance burden in needing to apply fixes to the secondary code. Instead a more likely near-term scenario is talk of moving ahead and just optimizing Mesa's src/mesa code with Gallium3D drivers in mind that in turn would lead to more classic driver obstacles or dead code, etc, but at the benefit to all the modern Gallium3D drivers. That presumably will garner support since there are no developers making serious strides on Mesa classic driver coverage.

Marek is pursuing these Mesa changes in an effort to further reduce the CPU overhead of Gallium3D driver and ultimately better the OpenGL performance for those current drivers. Brought up in the discussion was also a possible NIR-to-TGSI path for allowing Mesa's code to be better catered to the modern NIR intermediate representation without losing on TGSI support for those drivers using this traditional Gallium3D IR.

The ongoing discussion over these possible Mesa changes can be found on the Mesa mailing list.
Related News
About The Author
Michael Larabel

Michael Larabel is the principal author of Phoronix.com and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated benchmarking software. He can be followed via Twitter, LinkedIn, or contacted via MichaelLarabel.com.

Popular News This Week