DXVK 1.5 released with D9VK merged in for D3D9 support, plus a statement on DXVK's future

What i find interesting is the Crysis 3 bug fix, anyone knows if the game uses AMD ags, or it's just the "regular" dx11 path it's just that bad?

What i find interesting is the Crysis 3 bug fix, anyone knows if the game uses AMD ags

I don't think it does in any meaningful way, it's just that for some bizarre reason, the game takes a different code path that is significantly slower than the Nvidia path in terms of CPU performance.

And it's really bad. We're talking about going from ~23 FPS to ~30 FPS in some scenes, and that is on a Ryzen 2700X (which admittedly isn't very good for gaming, but not all that bad either).


Last edited by YoRHa-2B on 16 Dec 2019 at 2:47 pm UTC

Basically what he wants is to have a better tool to debug issues

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 think the more interesting comment at GitHub that caused the fuss is this one:

It'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:

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 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.


Last edited by KuJo on 16 Dec 2019 at 3:38 pm UTC

Does it being in maintenance mode means there will be no D3D12 support?

dx12 to vulkan is already been worked on by wine devs, and already part of proton

Does 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:
-> https://www.gamingonlinux.com/articles/jzef-kucia-wine-developer-and-founder-of-vkd3d-has-passed-away.14973

But Philip Rebohle has announced that he wants to contribute to VKD3D. At least that was his statement in November this year:
-> https://www.phoronix.com/scan.php?page=news_item&px=DXVK-Philip-More-For-VKD3D

Does it being in maintenance mode means there will be no D3D12 support?

There is a separate project for D3D12 to Vulkan support and, unlike D9VK which was a fork of DXVK anyway, it's a wholly separate codebase.

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.

I think people are just blowing what I said on Github (admittedly in frustration) WAY out of proportion.

Liam asked me to give the statement quoted in the article above today, just refer to that (and everyone, please stop annoying him via email about the whole thing).


Last edited by YoRHa-2B on 16 Dec 2019 at 4:36 pm UTC

Ok. Do I still need to put PROTON_USE_D9VK=1?

I think people are just blowing what I said on Github (admittedly in frustration) WAY out of proportion...

People blowing things out of proportion? On the Internet?? :D

Whatever phase of development you and your creation are in, thank you so much for DXVK, which brought gaming on Linux to a place many of us never imagined as being possible, and always let us know if you open a Patreon or something similar to assist your work .


Last edited by iiari on 16 Dec 2019 at 5:49 pm UTC

So, is it safe to say then that the games that still won't run in Proton are due to wacky code the developers have insisted upon in their games, such as Red Dead Redemption 2's Rockstar launcher?

On the one hand, it's good that DXVK has reached that level of maturity, but on the other hand, it's sad that certain games may never work on Linux.

What an amazing way to start the week, thank you Joshua and Philip.

Whatever phase of development you and your creation are in, thank you so much for DXVK, which brought gaming on Linux to a place many of us never imagined as being possible

Well said. Thank-you "YoRHa-2B" for your amazing contributions to Linux gaming!

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.

I think people are just blowing what I said on Github (admittedly in frustration) WAY out of proportion.

Liam asked me to give the statement quoted in the article above today, just refer to that (and everyone, please stop annoying him via email about the whole thing).

Yeah, people and several news sites jumping way to fast to conclusions or even worth, just want to create a quick headline (hey phoronix :)).
Anyway, having DXVK in a state where it is actually feature complete is moment to celebrate, I don't get why people are getting worried that it is time for bug fixing only. My impressions is anyway that 95% of all reported issues are outside of the scope of DXVK and the remaining 5% are not worth the attention due to being weird corner cases.

Thanks a lot for all your hard work. The sames applies to Joshua and other supporters as well.
I humbly bow before your work! Please allow yourself some rest after all the countless hours.


Last edited by jens on 16 Dec 2019 at 7:16 pm UTC

I 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. By the perspective of practical use, why the same machine should perform less just because the OS?

Come on Linux! You're almost at the point where I can finally leave windows behind! You just need to be a little better and fix some things that windows got it back in XP era.

[quote=YoRHa-2B]

And it's really bad. We're talking about going from ~23 FPS to ~30 FPS in some scenes, and that is on a Ryzen 2700X (which admittedly isn't very good for gaming, but not all that bad either).

Was 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.

Ok. Do I still need to put PROTON_USE_D9VK=1?

Good question

How hard is to create some automatic tests for DX11 + DXVK? Without some good tests is nearly impossible to refactor things

How hard is to create some automatic tests for DX11 + DXVK? Without some good tests is nearly impossible to refactor things

It’s FOSS. Create a pull request. I’m sure that it’d make contributing to the project easier.

How 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!