An interview with Gallium Nine project developer Axel Davy

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

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.