D3D9: Why It's Not a Part of Dolphin's Future

As many people have noticed, revision 4.0-155 removed D3D9 as a video backend, leaving D3D11 and OpenGL as the sole hardware backends in Dolphin. For the longest time, D3D9 was considered Dolphin’s fastest backend and was a favorite of Windows users. But then, why would it be removed?

While it was enjoyed by users, it was a source of endless frustration for the developers. D3D9 is inherently flawed, and working around its problems wasted time and slowed development. With D3D9 removed, the developers can focus their effort on making the emulator better instead of pandering to the ever growing demands of a flawed backend. This is why the D3D9 backend was removed.

D3D9: Inherently Flawed

Dolphin's D3D9 backend was mostly known for its speed. On AMD and Integrated Graphics cards, it is by far the fastest backend. But Direct3D9 is very old; it was released in 2002! Its age means that many modern features are simply not available for it, features that Dolphin needs for GameCube and Wii emulation. And that's where its speed came from. The D3D9 backend was as fast as it was because it simply didn't emulate certain effects. All kinds of modern functions are simply not possible in D3D9.

  • Line width / point size - Line width and point size are features of GameCube and Wii GPUs. D3D11 and OpenGL can emulate it with geometry shaders, but Direct3D9 doesn't support it at all. It can be faked in D3D9 with a bunch of hacks, but it is extremely difficult, invasive, and inaccurate.
Sunshine's transition effect is lines connected together. In D3D11 it is rendered properly, and you can't tell it is a series of lines.
...Unless you use D3D9
D3D11 and OpenGL properly emulating point size
D3D9 loves to make things bigger
  • Destination Alpha: Destination Alpha is a Wii GPU feature used by many games, but it can't be implemented cleanly in D3D9. There's only one D3D9 workaround: render things twice (dual-pass rendering). It isn't perfect and works well enough for most games, but it's a fairly complex chunk of code which is poorly contained, spreading across different files and messing up interfaces. D3D10 and OpenGL provide a feature called "dual source blending" which allows devs to implement destination alpha in a straightforward way. D3D9 actually has this feature too, but it's not widely supported and many of the drivers claiming to support it just crash if you use it, making runtime detection for support of this feature impossible.

  • Early_Z-test aka ZCompLoc: ZCompLoc is a feature of the GCN/Wii that allows the game to reverse the usual alpha test then depth test order. D3D11 and OpenGL support it thanks to very recent extensions, but D3D9 is incapable of this. A hack was used for D3D9, but it's incredibly ugly and is still broken in some games. The code is so ugly even the developers don't know why the hack works.

ZCompLoc working properly in Mario Super Sluggers with OpenGL
Even with the hack, ZCompLoc issues were still present. This is as good as D3D9 could ever get.

The D3D9 backend was annoying to keep around. Direct3D9 traces its roots all the way back to Direct3D5, the version of DirectX released in 1997. It's loaded with layer after layer of legacy code, making it a pain in the ass to work with. It's old fashioned, complicated, and ugly. Because of this, developers simply didn't want to work on it. And as D3D9 became increasingly different than the other backends due to its incompatibilities, more and more D3D9 bugs popped up requiring more and more of their attention. It was extremely frustrating for the developers. Because of the incompatibility and limitations of Direct3D9, any attempt to fix these bugs would involve complex hacks and messy code, or simply couldn't be done.

Furthermore, the D3D9 backend was the oldest backend in Dolphin. D3D11 was written in 2010, and OpenGL was rewritten in 2012/2013. The D3D9 backend, on the other hand, has its roots going all the way back to closed source releases in 2004. It has been patched up, hacked up, beaten and battered all that time. Dealing with all of this old code only adds to the complexity and difficulty of D3D9 support.

D3D9: Why the Other Backends Aren't Better

Since abandoning plugins in r6996, Dolphin has used a shared videocommon. This massively reduces redundant code in the emulator and makes things easier when adding new features. Unfortunately, this also means that any change in one video backend will affect all of them. With Direct3D9's incompatibility, features added for OpenGL and D3D11 would regularly break the D3D9 backend. Hacks would be written, limitations worked around, or the devs would simply ignore D3D9 altogether and let it break. Worse yet, some features cannot even be added because they would break D3D9 entirely, allowing no such workaround in the meantime. Such features would improve both the accuracy AND speed of Dolphin. The following features are all possible because of the removal of D3D9.

  • e.g. TEV: The most important piece in the Wii's pixel processing pipeline is TEV (Texture EnVironment). Failing to emulate it correctly will make lots of games show up with completely incorrect colors or missing graphics due to incorrect alpha test results (and other things). In particular, most TEV calculations are integer-based. GPUs traditionally used to do all their calculations with floating points and only recently added support for advanced integer math. D3D9 doesn't support many of the features needed for TEV, and such it was required to emulate integer math with floating points. It worked well enough for simple cases, but its slow and doesn't always work (Cf. issues 2098, 5325, 6683, 4570, 6442, 540 just to name a few, there are a lot more) and completely fails for more complex things (e.g. signed 24 bit integer emulation). Direct3D 10.0 and OpenGL 3 work with integers by default, but to implement integer shaders would require a complete rewrite of the shader generators, completely breaking D3D9.
TEV working properly in an experimental branch
TEV is currently broken in latest master, showing glitches like this in a number of games. With D3D9 around, this would be impossible to fix.
  • Transform Feedback: Vertex Loading is an annoying bottleneck in Dolphin's rendering pipeline, but it could be vastly improved by transform feedback. Which Dolphin can't use it because D3D9 doesn't support it.

  • Compute Shaders: Dolphin could move all texture decoding to compute shaders on the GPU for a nice speed boost; but that's not possible in D3D9. It has no support for compute shaders, and the regular shader pipeline is useless with the D3D9 feature set.

  • TONS of Direct3D11 and OpenGL specific optimizations are blocked by D3D9’s legacy feature set. While it could be possible to implement many them without removing D3D9, it would be far too much work for any of the developers to attempt. Since the removal, a ton of these options are being worked on thanks to the decreased difficulty.

Backwards Compatibility

A lot of people think that dropping the D3D9 backend means that Dolphin will lose compatibility with Windows XP. That's not true; Windows XP has full OpenGL 3.3 support. The OpenGL backend will continue to work on Windows XP. But the reality is, the developers have no obligation to support a twelve year old operating system. When a deprecated OS is significantly holding back the progress of Dolphin, then it should be dropped. The oldest version of OS X Dolphin currently supports came out just two years ago!

Furthermore, the D3D11 backend will work on any graphics card that supports Direct3D10. That means Geforce GTX 8xxx and Radeon 2xxx or newer can all use the D3D11 backend.

For the Future

Ultimately, the developers are the ones who have to maintain the emulator. They spend hour upon hour of their own time to maintain and improve Dolphin. There is only so much they can do. Removing D3D9 will make Dolphin better, fixing bugs and giving some speed improvements; but most importantly, it will make it easier for the developers to continue to develop Dolphin for years to come.

Special thanks to neobrain and degasus for mountains of technical information, Matt_P for clearing site headaches, JMC47 for writing help and proofreading, and Shonumi for help with the images

フォーラムでこの記事に対する反応を見る。

次の記事

前の記事

関連記事

内容の近い記事

  • No similar entries.