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
