GameCube and Wii emulator Dolphin drops D3D12 in favour of Vulkan

This is yet another Win for Vulkan over DX12, it's small wins like this we need, more vulkan usage amongst developers = more games on Vulkan which will make majority of new games playable, if not natively through wine with equal performances to Windows :)

Great news!

If you're the kind to see the thumbnail before reading the title, this post had very a different inference at quick glance.

Quoting: AnxiousInfusionIf you're the kind to see the thumbnail before reading the title, this post had very a different inference at quick glance.

Agreed, it looks like link is "dropping" Vulkan :D

With that said, dropping D3D12 (rather, not adopting it in the first place) makes a lot of sense for pretty much any multi-platform, but single purpose, engine.


Last edited by natewardawg on 4 June 2017 at 8:27 pm UTC

QuoteUnlike the D3D12 backend, the Vulkan backend is actively maintained and does not have the design flaws that made D3D12 harder to work with.

From the dolphin link progress report this sentence looks even more "interesting" than the one you quoted.


Last edited by lucinos on 4 June 2017 at 9:19 pm UTC

It all comes down to a simple situation: the guy that ported dx12 vanished and didn't keep supporting it. If he were still around giving dx12 support the situation would be different. It was nice that this emulator provided support for both APIs

Quoting: edoIt all comes down to a simple situation: the guy that ported dx12 vanished and didn't keep supporting it. If he were still around giving dx12 support the situation would be different. It was nice that this emulator provided support for both APIs

from reading more of their reports it looks more complicated and more in favor of Vulkan! Also supporting d3d12 leaving aside the double effort and more manpower is not good for compiling times as they say.

An other quote from the November report

Quote5.0-1241 - Vulkan Cleanup and XFB Support by stenzek

While it was originally planned to wait for Hybrid XFB to wire up Vulkan to the eXternal FrameBuffer, it turns out that feature is taking quite a bit longer than anticipated. Thus, in his latest block of cleanups, stenzek decided to plug Vulkan into the existing XFB code. It was a relatively simple task, and more or less makes Vulkan feature complete. This means that Vulkan can properly run games that require Virtual or Real XFB, such as Star Wars Rogue Squadron II: Rogue Leader.

In terms of overall quality, the Vulkan backend is shaping up nicely. Unlike D3D12, which is still plagued by a lot of instabilities, Vulkan seems to run well on any of the cards that support it. That said, it's not going to revolutionize Dolphin; its merely a bit faster than the standard D3D11 and OpenGL backends outside of a few rare cases, like The Legend of Zelda: Twilight Princess. While OpenGL remains the most accurate backend, Vulkan brings most of the performance of D3D12 without the instabilities in its current form.

In February a preliminary libretro Dolphin core was released, haven't really been tracking it further, but could be neat.

One of the devs posted on phoronix:

"No.

In most cases we found the D3D12 backend to be faster. It was faster because it did some threading tricks that the Vulkan backend currently doesn't do. However, that performance advantage slims significantly on higher end systems.

The D3D12 backend showed the most benefit for Intel iGPU users that could support D3D12, but not Vulkan. This was a lot of users. Intel iGPUs dominate our top GPUs used stat in analytics.

While it's unfortunate, we chose to keep the code base easier to maintain, and dropping D3D12 let us do just that. This was the biggest reason. Due to needing a very specific version of the Win10 SDK, retargeting the project to a new version every time the SDK updated wasn't feasible. As it requires buildbot admin coordination as well. And since we have no idea how microsoft intends to manage the Win10 SDK with VS 2017 which we recently migrated to, if microsoft chooses to constantly update it, that's a huge headache for us.

Additionally, the maintainer of the D3D12 backend pretty much disappeared after getting it merged to master, and due to the questionable quality of the code, none of the regular graphics devs wanted to touch it. It fell out of feature parity and users were frustrated that nobody was fixing anything in that backend."

Quoting: chimpyOne of the devs posted on phoronix:

"No.

In most cases we found the D3D12 backend to be faster. It was faster because it did some threading tricks that the Vulkan backend currently doesn't do. However, that performance advantage slims significantly on higher end systems.

The D3D12 backend showed the most benefit for Intel iGPU users that could support D3D12, but not Vulkan. This was a lot of users. Intel iGPUs dominate our top GPUs used stat in analytics.

While it's unfortunate, we chose to keep the code base easier to maintain, and dropping D3D12 let us do just that. This was the biggest reason. Due to needing a very specific version of the Win10 SDK, retargeting the project to a new version every time the SDK updated wasn't feasible. As it requires buildbot admin coordination as well. And since we have no idea how microsoft intends to manage the Win10 SDK with VS 2017 which we recently migrated to, if microsoft chooses to constantly update it, that's a huge headache for us.

Additionally, the maintainer of the D3D12 backend pretty much disappeared after getting it merged to master, and due to the questionable quality of the code, none of the regular graphics devs wanted to touch it. It fell out of feature parity and users were frustrated that nobody was fixing anything in that backend."

Odd, since that contradicts what their official update post (as quoted in the article) says.