Why Wine Developers Don't See Gallium3D D3D9 As An Option

While many Linux gamers are excited about the Gallium3D Direct3D 9 state tracker for offering better Windows gaming performance on Linux with the open-source drivers, the patches on the Wine side haven't been accepted upstream. Here's some clarification from one of the leading Wine developers on the graphics front to explain the opposition to the work.

Stefan Dösinger, the Wine developer and CodeWeavers employee who has wrote the Direct3D command stream patches (D3D CSMT) and other graphics/D3D-related functionality for Wine, presented at FOSDEM 2015 about some of the changes to Wine over the past year. He also used FOSDEM as a platform for explaining why he and other Wine developers are opposed to accepting the patches that enable the Gallium3D Nine state tracker. Meanwhile on the Mesa side, Gallium3D Nine is already part of the mainline codebase for implementing the D3D9 API as open-source for Radeon / Nouveau Gallium3D drivers.

In an email to Phoronix, Dösinger explained the problems with this Direct3D 9 approach:

My argument is this:

1) The state tracker adds another ~25,000 lines of d3d code to the existing 80,000 in Wine for only one corner case (New generation radeon GPUs on Linux playing d3d9 games). It will never be able to replace a single line of code in the existing codebase.

2) While it is faster than the existing code, it barely makes a dent in the performance difference between Mesa and Windows. -> A D3D implementation is therefore not sufficient to solve the performance problems. Performance problems also affect native Linux games just as much as Wine.

3) The Nvidia driver shows that a fast OpenGL implementation is possible. It performs as fast as Windows in both Linux native games and Wine's CSMT branch (*). -> A d3d implementation in Mesa is therefore not necessary to solve performance problems.

4) Mesa needs to improve its OpenGL implementation anyway for Linux-native games. Since Mesa (and Wine) have little manpower it would be much better to put the effort into one common codepath.

I realize that solving the remaining 20% of the problems requires 80% of the work and is generally not sexy. I also know I cannot command other people around in open source projects. I can only appeal to people to make Linux better as a whole as a gaming system rather than putting a lot of effort into some corner cases.

(*) I found performance problems on the GPU side. The Nvidia devs accept this as their bug and are trying to reproduce my results.

His points are certainly valid. Let us know what you think by commenting on this article in the forums.