Join us on our own very special Reddit: /r/Linuxers

An interview with Gallium Nine project developer Axel Davy

By - | Views: 17,351
Today I will interview one of the developers of the Gallium Nine project, Axel Davy.
Gallium Nine is a Direct3D 9 implementation for the Open Source Mesa drivers that use Gallium. Used with Wine, it enables you to play Direct3D 9 games with solid performance on Linux.

During this year's FOSDEM talk, Axel Davy gave a talk about Gallium Nine. Slides for the talk: slides

Talk about Gallium Nine by Alex Davy:

and Wines look on Gallium Nine by Stefan Dösinger:

So to the interview itself.

Q: Can you tell us something about yourself?

Axel Davy
I'm a Linux user, and have begun to contribute to the Gallium Nine project back in September. Gallium Nine is not backed by any company and only volunteers contribute.

Q: As one of few people contributing to the Gallium Nine project, can you say more about your involvement?

Axel Davy
Originally I wanted to help the project implement DRI_PRIME support (ie. support for laptops capable of switching between graphic cards). But when it was done, I found that it was quite cool to use it and saw it as a viable way to play my old games, and decided to keep on contributing.

Q: Can you explain what Gallium and the Gallium Nine state tracker are, and how they work together? Many of our readers probably haven’t heard of them before.

Axel Davy
One common complaint about OpenGL is that the different OpenGL drivers have sometimes different behavior, and what can be fast on one driver, can be slow on another one.
This problem is not present on Windows Direct3D, because the implementation is separated into two parts: the main dll that implements the interface, and the driver DDI, which is used by the main dll for the low level operations.
This architecture reduces the different behaviors on different drivers a lot. Moreover, a reference driver (software renderer) is available, so that the drivers can compare their behavior to it.

Mesa started as Open Source implementation of OpenGL. The OpenGL implementation talks to drivers via an API designed with OpenGL in mind. In 2008 a new internal API named Gallium was introduced. This API is used to implement the OpenGL needs, but also fits other ones. Drivers implementing this API are known as Gallium drivers, whereas the other ones are known as 'Classic Mesa' drivers.
The Gallium architecture is a bit similar to Direct3D: Gallium is a low level API talking to the Gallium drivers. The behavior of every function is well documented, and is low level (ie. no additional checks are required by the driver, if you did things correctly, calls will just work.).

The Gallium API is not limited to OpenGL, and is used for video acceleration and D3D9 (Gallium Nine) to name a few. A state tracker is how we call a backend that uses the Gallium API.

Currently all Mesa drivers use Gallium, except for Intel cards and very old cards.

Q: How did the Gallium Nine project get started?

Axel Davy
As far as I know, Joakim Sindholt started the project in 2010, which was originally an experiment to learn about GPUs. Christoph Bumiller boosted the project in 2013, and made it work with a lot of games. Today we are several contributors.

Q: From a technical point of view, was it easy to map Direct3D 9 into the Gallium API?

Axel Davy
When playing Windows games under Linux, ones usually use Wine. Wine implements Direct3D libraries by mapping Direct3D calls to OpenGL. The problem is that not all OpenGL implementations behave the same way. While their implementation is fast on NVidia driver, it is known to be rather slow on AMD Catalyst. Moreover a few things don't map perfectly to OpenGL or need extensions not all drivers implement.

Gallium Nine is an alternative implementation of D3D9. The state tracker converts the calls to the low level Gallium API. We don't have the same problems than Wine, because every Gallium API call has predictable behaviour and fast performance. Mapping Direct3D9 calls to Gallium API is most of the time easy, because the low-level API enables to do everything we need.

Q: What drivers are currently compatible with the Gallium Nine state tracker?

Axel Davy
Old d3d9 hardware has much more limited capabilities than D3D10 cards and above. That means to implement D3D9 perfectly for these cards, we need to use a few tricks and use some special hardware features. Since these cards are very old, the access to these hardware features in the Gallium API was removed (they don't exist on newer cards).
It should be possible to make Gallium Nine work for most games on these old cards, but since they are very old, and likely everyone has got a newer card in hand, we decided to drop support for them to avoid implementing the tricks they need.

The only D3D9 hardware we support currently is the AMD r500 cards (X1300 to HD2300). We support all D3D10 and D3D11 cards, except Intel cards, since their main driver is not Gallium. (A non-official Intel driver is available for Gallium, but it doesn't work well).

Q: Does working directly with the Gallium API give any advantages over a DX3D to OpenGL translation layer?

Axel Davy
First of all, we can have much lower overhead by needing to do much less checking. Wine has to do checks to verify the D3D calls are valid, and implement workarounds when the implementation should have special behaviors, and then the implementation has to check if the calls respect the OpenGL specification. Since Gallium is a low level API, we just need to do the checks once in the state tracker.

For games using D3D9 in several threads, Gallium Nine has an even bigger advantage over Wine, because it doesn't need workarounds to make OpenGL work OK (apparently OpenGL has some issues when using it with several threads).

For the shader code, D3D uses HLSL whereas OpenGL uses GLSL. D3D Applications pre-compile their shaders in binary. Since we know the application passes already optimised code, we can bypass optimisations, whereas Wine shaders will see an optimisation step (which can undo previous optimisations of the code). That results in faster compilation for Gallium Nine. Also for some reasons, Wine and Mesa OpenGL Gallium implementations like to delay shader compilation at draw call. This results in stuttering in game when a new shader is used. Gallium Nine doesn't have the same constraints and compiles the shaders directly when they are created.

Q: Some people might think that improving OpenGL layer would benefit Wine and Mesa much more, than implementing a separate and platform dependent solution. What do you think about their concerns?

Axel Davy
Mesa is the result of years of hard work of a lot of full time developers. It is a solid implementation, and respects the OpenGL specification well. The differences between OpenGL versions, the wide variety of applications, and the extensive API makes it hard for anyone that is not a specialist to master the codebase enough to be able to improve it.
On the other hand, the Gallium Nine project has a simple and short codebase. It makes it much easier for beginners to contribute.

Yes, improving the performance of the OpenGL backend is cool, but it’s not something everyone can do.

Also one has to consider that Gallium Nine is a user of the Gallium API. It is thus limited by the Gallium drivers' performance. Working on Gallium Nine helps find performance bottlenecks in Gallium drivers (and bugs), which results in a better OpenGL driver too.

Q: While Gallium API is very low level, it also binds Nine state tracker to Linux and drivers using it. Is there a possibility for Nine to be ported to other low level apis like Mantle or Metal?

Axel Davy
The Radeon and Nouveau Gallium drivers are Linux only, but some other Gallium drivers can work on other platforms.
If low-level enough, an efficient Gallium driver mapping to Mantle or Metal can be done. There is already an OpenGL Gallium driver in preparation (Virgil 3d project), but it is likely to be too limited to be used for Gallium Nine.

Q: Gallium Nine state tracker is mostly used by Wine, but what about native applications, will they be able to use it too?

Axel Davy
Gallium Nine can be used outside Wine by native applications. We have a simple demo running without Wine. However it is likely to come too late (given XP is out of date and in the near future it is likely all new games are going to drop D3D9 support). Also since the ports need to have an OpenGL backend anyway, they probably won't see reasons to add a Gallium Nine backend.

Q: While Wine is the primary user of the Gallium Nine state tracker right now, the support for it is still maintained outside the main Wine repository. Does this fact negatively impact your development efforts?

Axel Davy
The code in Wine to talk to Gallium Nine is only a few files. Most of the work is on the Mesa part.
Wine with Gallium Nine support is available on PlayOnLinux, and we wish to have Wine-staging support in the future.
The Wine files almost never need rebasing (a process of taking your changes and placing them on top of newer code from upstream), so we don't need to spend specific efforts on them, thus the answer is no.

Q: What parts of the Gallium Nine project still need more development and testing, and which ones are in good shape?

Axel Davy
Some behaviours of Gallium Nine are not entirely adequate and we are working on it to have exactly the expected behavior in all situations. Also Gallium Nine uses Gallium drivers in different ways than OpenGL, and some need fixing. Lastly, our Wine window handling code needs some updates to match the expected behavior better.

Q: What can an average gamer do to help?

Axel Davy
Not much. We know what needs work, and what is not working exactly as expected. In the future however, when most issues we have in mind are fixed, we'll need testers to find remaining issues.

Q: In the future, do you think it will be possible to also add support for D3D10 and D3D11 alongside the existing D3D9 infrastructure?

Axel Davy
Gallium used to have a D3D11 state tracker, but the Gallium drivers and Gallium API weren't entirely ready back then.
Rewriting a new one is always possible, but the best scenario is that it turns out not to be needed (cross fingers, OpenGL next is cool).

Q: One last question, are you concerned that Microsoft might take legal action against the project? I'm especially concerned about patents and recent API rulings.

Axel Davy
We follow Wine developers advice on the topic.

Thank you for your time. I would also want to thank you for your contributions to FOSS as a whole, without it many people would be unable to enjoy a wide variety of games that won't be ported to GNU/Linux.

P.S. If readers want to see more interviews with the FOSS developers, they can suggest their candidates in the comment section.
Also please link to this interview on Twitter, Facebook or your social media site of choice. Article taken from
Tags: Interview
1 Likes , Who?
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG and Humble Store. See more here.
About the author -
Chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken*

If you do not get the reference, it is your fault not mine.
See more from me
The comments on this article are closed.
Page: 1/2»
  Go to:

ripper 18 Feb, 2015
Great interview, thanks.
BTRE 18 Feb, 2015
View PC info
  • Contributing Editor
This was an interesting read. It's always nice to hear from the people directly involved. I've been following the project for a while and have been excited about its progress.
mirv 18 Feb, 2015
View PC info
  • Supporter Plus
Good interview questions, good read.
It's projects like that have made Gallium a really good investment of developer effort, and is another reason we should all encourage continued FOSS driver development above blobs (if for no other reason, FOSS drivers fit in with the general Linux graphics stack much better).

I really should tidy up my system and get wine running properly on it again one of these days.
edmondo 18 Feb, 2015
Thanks for the interview. Well done!

It would be great if you could interview mesa developers like:
1. Marek Olšák (I also really like all AMD open source developer, Alex, Christian, Michel, Tom, ...)
2. Ilia Mirkin (I'm impressed about his work)
3. Grigori Goronzy (I would love to know more about him and see a company sponsors his work full time for mesa)
4. Brian Paul (I mean, Brian is mesa)
5. Matt Turner, Ian Romanick, Kenneth Graunke and many other Intel developers
6. Oh well, maybe it's easier if you interview everybody. My wish list will never end :-)
pd12 19 Feb, 2015
Good article and interview! =) Quite informative for me as I only use nvidia's proprietary drivers and didn't care about the implementation of them or other drivers.
Segata Sanshiro 19 Feb, 2015
Quoting: edmondo6. Oh well, maybe it's easier if you interview everybody. My wish list will never end :-)


Also, it might be cool to have a picture of the person (if one is available) in the article. It's nice to see the names and faces behind free software :)
Shmerl 19 Feb, 2015
Interesting interview, thanks!

QuoteQ: One last question, are you concerned that Microsoft might take legal action against the project? I'm especially concerned about patents and recent API rulings.

Axel Davy
We follow Wine developers advice on the topic.

What advice is that exactly?
ElectricPrism 19 Feb, 2015
Very good read.

I tried to run the Gallium PlayOnLinux "wine-1.7.34-gallium-nine-x32" and I couldn't install vcrun2005, vrun2008, etc...

My goal was to run StarCraftII on Gallium Nine as I can only get to High out of Extreme graphics settings and thought It would boost the capabilities of my new GTX 970.

I'm running the blob 346.x, It's a shame AMD hasn't fully open sourced their R9 290x driver yet because I would have rather dropped the $400 I spent last week on a AMD open source card, but hey - I need my PC to work _right now_ as I use it for work and gaming and can't affort to buy into the pipe dream until they deliver.

I was really excited about the HSA driver and Kernel 3.20 on my Arch Machine unfortunately It's my understanding that the R9 285 - R9 295x will require another AMD driver that hasn't been open sourced yet.

Maybe I'll give my GTX 970 to my girl and get me a AMD when they deliver, until then:
how I learned to stop caring and love the blob :)
mirv 20 Feb, 2015
View PC info
  • Supporter Plus
What haven't AMD released for the R9? I understood all the required docs have been released, and it was all supported by radeonsi. Granted, radeonsi needs some performance improvements, but there's no need for another driver.

If you're thinking of amdgpu, that's the new thing AMD is working on. There's no guarantee that it will be released for Sea Islands (that's just a working prototype, probably until the 3xx series cards are ready). As we have radeonsi, that's not a real problem.

Just find Alex Deucher's speech about it, he does mention while they have working prototype code for amdgpu with Sea Islands, they aren't sure if that will hit upstream, and they would prefer not to have two open source drivers for the same hardware. So it's likely to be 3xx and beyond hardware only.
SXX 21 Feb, 2015
Quoting: mirvJust find Alex Deucher's speech about it, he does mention while they have working prototype code for amdgpu with Sea Islands, they aren't sure if that will hit upstream, and they would prefer not to have two open source drivers for the same hardware. So it's likely to be 3xx and beyond hardware only.
Everything is even more simple. Linux upstream standards/rules doesn't allow multiple drivers for one device so Linus just not going to merge it. Also you're a bit incorrect about 3xx because R9 285 (Volcanic Islands) don't supported by Radeon so it's will be first graphics card using AMDGPU.

Though that's all have nothing do with Mesa because userspace driver for R9 285 and 3XX likely will remain RadeonSI.
While you're here, please consider supporting GamingOnLinux on:

Patreon, Liberapay or PayPal Donation.

We have no adverts, no paywalls, no timed exclusive articles. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.
Livestreams & Videos
Community Livestreams