Intel Possibly Working on Modern Gallium3D Driver for Linux Gen 9 Graphics

While Intel has been seemingly ignoring Gallium3D for nearly a decade in favor of continuing to maintain the i965 Mesa classic driver for Linux, due to how much they’ve invested into its compiler stack and other functions, it appears that Intel’s open-source development team may be shifting some focus towards starting up development for a modern Gallium3D driver.

It has not been formally announced as of yet, but if you read the latest patch series on the Mesa mailing list from earlier today closely (by Intel’s Jason Ekstrand), you’ll notice the mention of one of the benefits of a storage image lowering pass for NIR being “this will make Ken’s life way easier as he tries to hook up images in the new Gallium driver.” – which is kind of like an unofficial announcement, right?

Of course, this should not be confused with the former i915g or i965g efforts from nearly a decade ago, which were the products of an experiment by Tungsten / LunarG for driver research and experimentation purposes, or with regards to the i915g trying to handle some of the features found in LLVM in certain software – instead, this could be a modern Gallium3D driver that will target their modern and current hardware.

If we speculate who the “Ken” being referred to in the mailing list is, it is most probably Kenneth Graunke, a longtime contributor to the Mesa and open-source driver development efforts – and he indeed most recently migrated his personal repos to the new Gitlab, which contains a recently updated “Iris” branch update in his Mesa repository, and it definitely contains an Intel Gallium3D driver.

This isn’t some personal side project either, because the commit history shows us that the new Iris Gallium3D driver has been worked on for the past several months – the past eight months, to be exact. And while the Iris Gallium3D is slowly taking shape, it appears that the driver still has a lot of work ahead for DRI3 and handling some of the advanced OpenGL features such as the Mesa shader disk cache, compute shaders, and also the primary support targets appears to be focused to the current-generation of “Gen 9” graphics, not older Gen 8 hardware or the future Gen 10 Cannonlake and Gen 11 Icelake graphics.

So assuming everything goes smoothly and Intel makes an official announcement sometimes in the future, it appears that there is definitely an Intel Gallium3D driver called “Iris” being developed, and it will be extraordinarily interesting to see how much time and energy Intel puts into it, considering their Vulkan drivers continue to be successful along with the ANV drivers. This could work out however, as the maturity of several Mesa drivers and NIR which center around this intermediate representation, which makes changing over to Gallium3D a lot more feasible than it was in previous times – the vetted NIR compiler is being used by Iris in fact.

If Intel should go with Gallium3D, they’ll have the ability to utilize the Gallium Nine state tracker, which will enable much faster Direct3D 9 support in Wine, possible compute support in Clover, and more code sharing between the various open-source Gallium drivers – including various Gallium state tacker possibilities such as VA-API / VDPAU video acceleration, although Intel already has an independent VA-API driver implementation. Not to much that they also already have the separate Beignet and OpenCL-NEO projects, which offer great OpenCL support currently.

Intel has used the Iris codename in other projects previously, for branding some of their high-end graphics over HD/UHD Graphics – which could possibly mean that this Iris Gallium driver stack is going to be a part of their future planning for Intel’s discrete graphics card rumored to be released in 2020 – we’ll be following these developments closely, so stay tuned!

Kamil Anwar

A former British Computer Society Member with over 9 years of experience Configuring, Deploying and Managing Switches, Firewalls and Domain Controllers also an old-school still active on FreeNode.