Support us on Patreon to keep GamingOnLinux alive. This ensures we have no timed articles and no paywalls. Just good, fresh content! Alternatively, you can donate through PayPal, Flattr, Liberapay or Buy us a Coffee. You can also buy games using our partner links for GOG and Humble Store.

With the news earlier about D9VK being merged into DXVK, to make DXVK the all-in-one solution for D3D9, D3D10 and D3D11 to Vulkan - we now have a fresh release of DXVK with it all together.

Today, DXVK 1.5 is out and the big headline feature there then is D3D9 support included! D9VK did actually have a standalone release just before all this happened with D9VK 0.40/0.40.1 and this DXVK release includes a few extra fixes too.

What does all that above mean? Simply put: DXVK will now run games that use D3D9, 10 and 11 and turn it into Vulkan when paired with Wine/Proton as of DXVK 1.5.

In this release the HUD you can enable gained an improved overall appearance, it can also now show the amount of memory allocated per Vulkan memory heap "which allows distinguishing between video memory and system memory allocations" and draw call and queue submission statistics are now updated every 0.5 seconds to make them more readable.

A few game-specific fixes made it in for Atelier Ryza, Crysis 3 (all GPUs now reported as NVIDIA), Halo MCC and Star Citizen.

See the full release notes here.

On the subject of DXVK possibly going into "maintenance mode", something a few others picked up on due to a comment on the DXVK GitHub. I spoke today to DXVK creator, Philip Rebohle, who said this to me:

Basically, not too much will change, bugs will still get fixed and if a game requires a feature to run, it'll get implemented. DXVK has been more or less feature-complete for a while now, and most of the changes in the 1.4.x releases were bug fixes and some optimizations anyway. What I want to avoid going forward is large-scale changes to the code base since those are prone to introduce breakage, and it's really getting harder and harder to debug any new issues.

So, nothing really changes. It continues on getting additions and fixes where it's needed.

Article taken from
33 Likes, Who?
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG, Humble Store and Paradox Interactive. See more information here.
About the author -
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
Page: «3/3
  Go to:

lectrode 16 December 2019 at 10:34 pm UTC
ziabiceHow hard is to create some automatic tests for DX11 + DXVK? Without some good tests is nearly impossible to refactor things

It has tests to catch regressions. That's not the deterring factor. DXVK is at a point where it's very stable and works for most things. Any changes introduce risk breaking it for something. Even if all known tests pass after a change, there's always a chance you run into random quirks or race conditions or any number of different issues that only manifest once the changes have been tested by a wider audience.

DXVK already has a ton of workarounds implemented for specific devices, drivers, and games. These were usually for instances where game/device/driver devs made incorrect assumptions or only targeted specific combinations/vendors, or where a game uses features available in some devices/drivers but not others (not to mention potentially problematic workarounds built into games to get around still other issues/quirks). Large changes would likely reveal even more quirks that need workarounds - that's a lot more work for little to no gain.

BUT, if you feel it still needs something, you're welcome to contribute your solutions!
raneon 16 December 2019 at 10:43 pm UTC
Really great to see D9VK being integrated to DXVK now :-) So I assume that Proton will enable D9VK now by default. I'm still amazed of how much both projects achieved in this short time frame! Due to them I own now many Windows games, but combined with Vulkan I couldn't resist adjust my purchase strategy...
gardotd426 16 December 2019 at 11:38 pm UTC
QuoteOn the subject of DXVK possibly going into "maintenance mode", something a few others picked up on due to a comment on the DXVK GitHub.
I think the more interesting comment at GitHub that caused the fuss is this one:
QuoteIt's because DXVK has become a fragile, unreliable and frustrating maintenance nightmare. Most of the 1.4.x releases introduced major regressions which I cannot reproduce, and therefore cannot debug and fix.

This includes GPU hangs in Overwatch on specific maps with Nvidia GPUs (some users claim it's fixed in 1.4.6 while others still have them), rendering issues in Dishonored 2 which I can't reproduce (see ValveSoftware/Proton#823 (comment)), vertex explosions in some games which I also can't reproduce, an ongoing Star Citizen issue which I still need to debug (see #1262), and tons of weird issues that don't make any sense whatsoever (like #1266 which only seems to affect RADV).

Most of these problems are still unresolved and I have no idea how to even track them down, let alone fix them, and the ones that got "fixed" got fixed by reverting otherwise useful changes because I simply do not understand any of the issues at all.

Doing any sort of active development with this broken mess of a code base would only make this worse, and I wish I had drawn the line sooner. The only thing I still plan to do is wire up some useful Vulkan extensions and eventually merge D9VK, the rest will be bug fixing only.

This comment expresses a certain degree of frustration. And that there are problems that are no longer solved. Also the statement that the line should have been drawn before doesn't sound as if there will be special fixes for single games in the future. Either a game runs with the status of DXVK or it just doesn't work:

QuoteThe only thing I still plan to do is wire up some useful Vulkan extensions and eventually merge D9VK, the rest will be bug fixing only.

This is a significant change in development.

But don't get me wrong! I can understand him (I am a developer myself (SAP ABAP) and know what he is talking about) and understand his decision. And I am endlessly grateful to him for making it possible for me to play almost like a Windows gamer under Linux. But we should be aware of that.

DXVK will not disappear and will continue to make sure that many Windows games will run with good performance under Linux. But if this doesn't work with some games, there won't be any special adaptations or fixes anymore.

At least if this comment is still valid on GitHub from December 10th. His statements he made to GOL now actually sound a little different.

He literally said in the quote from this article that if a new game comes out and it needs something, it will be implemented when possible. What it sounds like is that he was burnt out and frustrated with trying to fix these bugs he couldn't even find the cause of (which I can attest to, I've been seeing him seem to get a little despondent lately on the issues threads for dxvk, mainly in regard to not being able to nail down causes), and he made those comments on github which probably did reflect how he truly felt, but after a couple days and some time to decompress, he's backed off, albeit only slightly. We probably won't see any more huge development on dxvk, but that's because it's pretty much feature-complete, as he said. So now it will be bug-fixes and new stuff for new games when needed, as he said more recently. Usually when someone says two slightly differing things, it's best to take the more recent one as most accurate.
gardotd426 16 December 2019 at 11:40 pm UTC
PatolaDoes it being in maintenance mode means there will be no D3D12 support?
D3D12 support will not come via DXVK. This will come via VKD3D of the Wine project.

Unfortunately the development of VKD3D has stalled due to the death of Jozef Kucia as main developer:

But Philip Rebohle has announced that he wants to contribute to VKD3D. At least that was his statement in November this year:

vkd3d lost its main dev, yes, and that's a huge loss, but vkd3d is absolutely still being actively developed.
TheRiddick 17 December 2019 at 2:14 am UTC
Someone over at the DXVK issue section mentioned that the DXVK hud didn't work with this release? I'm not sure how true that is.
YoRHa-2B 17 December 2019 at 2:55 am UTC
ziabiceHow hard is to create some automatic tests for DX11 + DXVK? Without some good tests is nearly impossible to refactor things
Wine has a whole bunch of tests for D3D11. Thing is, it is impossible to catch all possible use cases and the... let's just say creative ways some games use the API. It is also not really possible to accurately test whether thread synchronization works correctly in all cases etc., and undefined behaviour sometimes works on some hardware but not on others. Writing tests alone just doesn't cut it.

tamodoloI wonder. How much close to windows performance DXVK will be capable to achieve? Now it's somewhat 80% of windows performance. I find that awesome but at the same time not enough.
Depends very much on your hardware and software setup.

On my AMD setup, DXVK is consistently faster than Windows driver in CPU-bound scenarios (because their driver is ludicrously slow in some cases) and usually only marginally slower when GPU-bound (depends on which Vulkan driver you use, though, and some games still lose quite a bit of perf simply due to being dumb). I recently made a video running the FFXIV benchmark; in some scenes, native D3D11 is slightly faster, in others, DXVK is slightly faster. It's rare to see games lose more than 10-15% compared to Windows.

On Nvidia, D3D11 tends to work a lot better in CPU-bound scenarios (as it should, since we're doing quite a bit of extra work that a native driver doesn't need to care about), and at the same time, their Vulkan driver also seems to have some drawbacks. There are some weird performance issues that are not specific to DXVK, i.e. some workloads just perform worse with Vulkan than with D3D11 no matter how hard you optimize the Vulkan path. Older architectures such as Kepler are especially bad and only reach ~50% of native performance.

D3D9 is slow on Windows, even with an Nvidia GPU. D9VK can beat that in many cases, but not all.

On Linux you also need to work around performance issues caused by power management and the scheduler, I run a custom kernel with PDS for that reason and put the CPU into performance mode when playing. There's also wine overhead to take into account, you'll want to use Fsync to minimize thread synchronization bottlenecks, which also requires a custom kernel.

TL;DR don't expect any massive improvements anymore. Getting a decent experience on Linux takes some effort and slightly stronger hardware, that's just the cost of running games on an unsupported platform through a compatibility layer.

Last edited by YoRHa-2B on 17 December 2019 at 3:44 am UTC
TheRiddick 17 December 2019 at 3:04 am UTC
Some games will alter their code drastically to work around bugs, its common with NVIDIA stuff since their drivers don't attempt to be conformance.
IF you develop a game on only NVIDIA hardware it will likely simply not work on AMD hardware, funny that. (only terrible devs do this btw!)
KuJo 17 December 2019 at 11:00 am UTC
The distribution/support of DX12 in upcoming Windows games will continue to increase.

Under this aspect it will be interesting to see what VKD3D will be able to achieve.
STiAT 17 December 2019 at 4:31 pm UTC
Nice, especially the merge of D9VK.

I'm not worried at all that DXVK enters maintenance mode. Maybe they can make some good use of certain Vulkan extensions in future, but well, I played several (a lot of) games using DXVK which I had issues with in Wine.

Most issues I have linux gaming are most likely wine bound. Things not starting properly, hanging on closing etc.

Though, I hope for this release to be soon packaged with proton.

And I'll have to look what's up with D9VK and DragonAge: Origins which shows not very nice rendering issues in character creation. Or did in the past. And there is no bug report to be found for this (but the character selection seems to be somehow broken anyway, had it's fair share of issues in Wine too).
YoRHa-2B 18 December 2019 at 4:31 pm UTC
aufkrawallWas this with a Vega or Navi GPU?
This game triggers some weird bug of completely broken CPU performance that is shared between Windows and Linux on these GPUs.
Yeah, it sounds too weird too be true, but CPU performance in critical situations, like tons of grass, is quite twice as high on Polaris in my testings.
No, this was with Polaris.

The grass level ironically performs quite well (even my old Phenom can maintain reasonable framerates), but some scenes in the intro level tank massively, and for no appaent reason at that.
  Go to:
While you're here, please consider supporting GamingOnLinux on Patreon, Liberapay or Paypal. We have no adverts, no paywalls, no timed exclusive articles. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!

You need to Register and Login to comment, submit articles and more.

Or login with...

Livestreams & Videos
Community Livestreams
  • MMOre Fun: „World of Warcraft“ (Wine/DXVK)
Popular this week
View by Category
Latest Comments
Latest Forum Posts