Wine Developers Not Yet Convinced By Direct3D 9 In Mesa's Gallium

While Direct3D 9 support in Gallium3D is moving along and will quite likely be merged to mainline Mesa, the Wine developers aren't yet interested in accepting patches to allow this Gallium3D state tracker to be used for increasing the performance of D3D9-using Windows applications.

The Gallium3D "Nine" patches allow for vastly better Linux gaming performance with Wine games when compared to using Wine's Direct3D-to-OpenGL translation layer that's otherwise used for running these Windows games on Linux and OS X. The results have been very good for Gallium3D driver users with the open-source Radeon driver in some cases then outperforming the Catalyst proprietary driver with Wine.

While end-users are happy about the performance and resort to patching their build of Wine to use this state tracker, Wine and CrossOver developers haven't been optimistic about merging the patches. On the Wine side, they aren't interested in adding another Direct3D layer that can't be used universally across platforms -- or even across just the Linux drivers. The "Gallium3D Nine" support is limited to just Gallium3D drivers, which is a subset of all Linux graphics driver users -- leaving out the Intel Mesa driver and the proprietary Linux graphics drivers. There's also been other concerns about ensuring a stable API, integration issues, etc.

On the Mesa mailing list has been another thread about Wine and this Gallium3D state tracker. In the thread today, Henri Verbeet of CodeWeavers re-affirmed, "in it's current form this is not something we'd merge." He later elaborated on the matter:

The main issue is probably that we'd really like to avoid having two parallel implementations of the high-level d3d9 stuff. I.e., anything dealing with (d3d9) devices, stateblocks, swapchains, etc. We'd potentially be open to using something closer to the Gallium interface instead of OpenGL on the backend in wined3d. In that scenario wined3d would essentially be the statetracker. The main issue with that approach has always been that the Gallium statetracker/driver interface isn't meant to be stable, and neither is the internal interface between wined3d and e.g. d3d9. (So it wouldn't help to e.g. move wined3d into the Mesa tree either.)

Another consideration is that while the Gallium interface is a better match than OpenGL for Direct3D in some places, I'm not necessarily convinced that that's something that couldn't be fixed with appropriate GL extensions. To give an example, it's possible that translating D3D bytecode to TGSI instead of GLSL ends up with better shader code for the hardware. Unfortunately that kind of analysis is completely missing as far as I'm aware, but if that were the case, it would probably be fixable by making some improvements to the GLSL compiler. If that's not possible for some reason we could consider adding an extension for authoring shaders in TGSI instead of GLSL, and so on. I guess the basic point is that replacing OpenGL is a pretty big hammer, that would need corresponding amounts of analysis and justification.

While the discussion is still ongoing amongst Wine and Mesa developers, for now it looks like users will be left having to patch their own Wine build if wishing to use this open-source D3D9 implementation atop Gallium3D. Fortunately, there's plenty of PPAs and other package sources for end-users wishing to obtain pre-built, modified versions of Wine.