Gallium Nine, end of the road

[Axel Davy]

Hi there.

I think this will surprise no one here, but here we are. I think it's 
time for Gallium Nine to end.

Long story short, Gallium Nine was a success. Its purpose is fulfilled. 
But there is not enough reasons to keep it around.

Gallium Nine doesn't have enough users anymore and it totally makes 
sense why. DXVK just works. Gallium Nine might get you a little less CPU 
usage or a few more fps, maybe.
But as PCs have caught up, and users have moved to shinier games with 
newer APIs, Gallium Nine is not relevant in the current landmark.

There has been no new volunteers to work on gallium nine for a long 
time, and regressions take a long time to get noticed.
Not breaking Nine puts effort on driver devs.

For all these reasons, unless there is vigorous protestations here, I 
will propose a PR to remove gallium nine.

Thanks,

Axel Davy


===== Long Version =====

Gallium Nine came at a different time. 2014. Ten years ago.

Back then, playing on Linux was very complicated. There were very few 
games supported natively, and performance was not always great. Wine did 
exist, but many games ran very poorly, or not at all. Games used to 
stutter a lot due to long shader recompilation times during rendering. 
Both OpenGL support and Wined3d had significant overhead.

After some small contributions to Wayland and DRI_PRIME support, and AMD 
llvm backend, I decided to help Gallium Nine get in shape to get merged 
in Mesa. Gallium Nine had been created mainly by the fabulous work of 
Joakim Sindholt and Christoph Bumiller a few years before (as soon as 
2011), and it only lacked some work to get in proper shape to get into 
Mesa mainline. And a maintainer. We got merged on 18/11/2014.

With the help of very friendly contributors, testers and mesa 
developers, we managed to provide a solid D3D9 implementation. For a 
long time, there was a significant interest to using Gallium Nine over 
Wined3d. It was a much smoother experience, speed was on par with 
windows and games had fewer visual bugs.

But not everything was perfect. For a long time AMD was the only 
supported backend. In addition a special wine build was needed. This 
second issue was later solved, but to this day Gallium Nine still relies 
on some internal wined3d interface (which for some time was removed in 
the proton build). Unfortunately we never managed to truly talk the same 
language with wine developers, and we didn't manage to make any 
meaningful contribution to the wine project or to get some proper 
gallium nine entry points. One of the contention point is that when the 
mesa-wine interface of Gallium Nine was designed, I was using a modest 
GPU on a dual GPU system (laptop with a hd7730m). There were significant 
issues at the time with DRI_PRIME due to synchronization and Gallium 
Nine was an opportunity to showcase a different approach (early on there 
was the possibility of sending buffers which had totally finished 
rendering, thus avoiding any synchronization issue). Furthermore we 
could control vsync and tearing to behave more closely to the d3d9 spec 
behaviour, which is different to what OpenGL did. For all these reasons, 
I chose to implement an interface that would handle the presentation to 
the X server directly using the then brand new PRESENT and DRI3 
extensions. But for that to work properly with wine, we need to be able 
to have access to the X window, and have some feedback from wine to 
handle some window events. The alternative that was encouraged at the 
time was either to contribute to wine and drop nine, or to send the 
rendered buffer to OpenGL to then submit the content of the frame. This 
meant a buffer copy and for my poor GPU that meant a significant enough 
performance drop.

If a newer interface was to be done today to be able to support Wayland, 
probably it would make more sense  to go with the solution 'use OpenGL 
or Vulkan' to present the content using wine. Because Wayland support 
might need even more interactions with wine internals, and because 
avoiding buffer copies or being respectful to the D3D9 spec to have 
better behaviour when fps is below the screen refresh rate are much less 
relevant.

But again, today is a very different landscape. OpenGL support has 
hugely improved. DXVK is around, supports all hardware, more games than 
Gallium Nine and is well maintained with an active community.

Gallium Nine showed that it was possible to achieve performance on par 
with Windows. It participated to the movement to make Linux a gaming 
platform. Gallium Nine was used and helped Linux gamers to get a good 
gaming experience before DXVK was a thing. DXVK used Gallium Nine as a 
code reference and having it around helped a lot.

Thus this removal doesn't mean that Gallium Nine was a failure. On the 
contrary, it was a success.

I think in some sense we all look to put some meaningfulness in our 
contributions. Yes Gallium Nine can be improved. It can be made Wayland 
compatible. It can be made to work with non-x86 hardware. Some missing 
features can be added. But I feel like in today's landscape there is not 
enough interest for such a work. And, on the other hand, keeping Gallium 
Nine around in Mesa can cause headaches for driver developers when they 
have to avoid breaking existing frontends.

I shall not name anyone in fear of forgetting someone, but I want to 
give huge thanks to all the many people involved in this fantastic 
project that was Gallium Nine.

Thank you !

Axel Davy