We do often include affiliate links to earn us some pennies. See more here.

DXVK 1.2.2 released with performance improvements and bug fixes

By - | Views: 16,962

DXVK, the incredible project that provides a Vulkan-based layer for D3D11 and D3D10 games run with Wine has another release now available. DXVK 1.2.2 is quite a small point release but as always, it still brings with it some nice changes.

This time around Team Sonic Racing has a bug fix to help some startup issues and Planet Coaster should also see less startup issues, although Planet Coaster does need "additional wine patches" as of Wine 4.10.

Also in this release are some CPU overhead optimizations, improved compute shader performance on Nvidia GPUs in some games with Nier: Automata being one that was noted and minor bugs were solved that caused wine test failures.

You can see the full release notes here on GitHub.

Interestingly, one of the actual Wine developers recently called DXVK a "dead end". That comment might seem a little bitter by itself, but explaining it further (more detail again here) they said that essentially "Wine's own Vulkan D3D backend should make DXVK superfluous in the long term". It will be interesting to see the work the Wine team are cooking up officially, when it's ready. However, DXVK is already here and working well for Steam Play. It will be fun to see just how many more optimizations can be done, as it does already perform very well in a lot of games compared to Wine by itself.

Article taken from GamingOnLinux.com.
18 Likes
About the author -
author picture
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. Find me on Mastodon.
See more from me
The comments on this article are closed.
19 comments
Page: 1/2»
  Go to:

vipor29 Jun 15, 2019
it is unreal on how well dxvk is.i have tested this compared to windows and yea it just blows it away.games that were never intended for vulkan it just helps it out so much.
gradyvuckovic Jun 15, 2019
At this point I think it's fairer to call WineD3D a dead end, since that project has been going on for much longer and is no where near DXVK and D9VK's level, and is coded in a much less modern language and older tool..

The particular Wine dev in question who made that comment, would do well to remember the old wise words always uttered for programming and that never cease to be relevant: "Never re-invent the wheel".

He or she would do well to consider maybe just accepting that the Wine project team doesn't need to create every component of Wine themselves, that they could just embrace the tactic Valve has used of just integrating multiple components together like puzzle pieces in order to make a larger more complete package, like Valve have done by integrating Wine, DXVK, FAudio, etc.. all together into one package and calling it 'Proton'.

There are many areas Wine is still lacking for which there are currently no fixes available, areas which would be better use of their time than recreating an existing highly successful solution. It is still not possible even with Wine 4.10 to run some common and much desired applications (off the top of my head, Adobe Illustrator is still unusable for example) that could be focused on instead.

It would also be worth considering.. perhaps not referring to a very successful project filling a crucial gap left by Wine, as a 'deadend'. A better (and more respectful) choice of words would have been nice.


Last edited by gradyvuckovic on 15 June 2019 at 6:00 pm UTC
1xok Jun 15, 2019
QuoteInterestingly, one of the actual Wine developers recently called DXVK a "dead end".

Haven't there already been misunderstandings between the DXVK authors and the Wine team?

I think it's a pity because such undertones can demotivate people. Besides Wine, DXVK is currently Proton's most important component.

I will test Nier: Automata again next time. It already ran incredibly well on my GTX 970 months ago.


Last edited by 1xok on 15 June 2019 at 6:06 pm UTC
Munk Jun 15, 2019
Before everyone takes offense, hear him (Henri Verbeet) out. I'm not taking sides, but here's the "elaborate explanation" he's referring to in the post linked to the article: https://www.winehq.org/pipermail/wine-devel/2019-January/138023.html

Personally, I don't think he was as tactful as he possibly could have been in his recent comments, but far more than he could have been. I don't really mind the odd off-color comment from developers. Even Linus himself is known to express frustration with less than cordial responses. It seems that he's frustrated and might have let that affect his tone ever so slightly. I don't see a need to jump down his throat.


Last edited by Munk on 15 June 2019 at 6:18 pm UTC
gradyvuckovic Jun 15, 2019
Quoting: MunkBefore everyone takes offense, hear him (Henri Verbeet) out. I'm not taking sides, but here's the "elaborate explanation" he's referring to in the post linked to the article: https://www.winehq.org/pipermail/wine-devel/2019-January/138023.html

Personally, I don't think he was as tactful as he possibly could have been in his recent comments, but far more than he could have been. I don't really mind the odd off-color comment from developers. Even Linus himself is known to express frustration with less than cordial responses. It seems that he's frustrated and might have let that affect his tone ever so slightly. I don't see a need to jump down his throat.

Have to say, after having read that.. That doesn't change my opinion.
massatt212 Jun 15, 2019
DXVK & D9VK are so nice buuuuuut the shader stutters :'(
Munk Jun 15, 2019
Quoting: massatt212DXVK & D9VK are so nice buuuuuut the shader stutters :'(
The shaders need to be compiled when they first run, which can stutter the game. Once they've been compiled and cached, everything should be smooth (until a new shader needs to compile). Obviously this is a less than optimal experience, so Valve's already rolled out a solution to this with Proton - steam downloads the shader cache with the game, so everything's ready to go.

If you're playing without Steam and Proton, I don't think there's much you can do about this other than have the shaders run and compile, knowing that the next time they run they won't stutter.
massatt212 Jun 15, 2019
Quoting: Munk
Quoting: massatt212DXVK & D9VK are so nice buuuuuut the shader stutters :'(
The shaders need to be compiled when they first run, which can stutter the game. Once they've been compiled and cached, everything should be smooth (until a new shader needs to compile). Obviously this is a less than optimal experience, so Valve's already rolled out a solution to this with Proton - steam downloads the shader cache with the game, so everything's ready to go.

If you're playing without Steam and Proton, I don't think there's much you can do about this other than have the shaders run and compile, knowing that the next time they run they won't stutter.


The AMDGPU PRO 19.20 Driver Reduces Stutters to almost 0 but video is broken on so many games
And i do use the beta version of proton and games like soul calibur stutter so badly. Once stuttering is solved DXVK will be perfect it already performs close to windows and sometimes beats it in performance
bolokanar Jun 15, 2019
I have one and only question: But does Witcher 3 get performance like on Windows?


Last edited by bolokanar on 15 June 2019 at 7:33 pm UTC
minidou Jun 15, 2019
QuoteInterestingly, one of the actual Wine developers recently called DXVK a "dead end". That comment might seem a little bitter by itself, but explaining it further (more detail again here)

I guess it all comes to the already much discussed January comment :

QuoteI learned about DXVK either near the end of 2017 or near the start of
2018. In February 2018, we reached out to Philip Rebohle—the author of
DXVK—to start a conversation around whether there were any areas we
could cooperate on. One obvious area was the vkd3d shader compiler,
which translates Direct3D shader byte code to SPIR-V (much like DXVK
has to do), but there would have been other possibilities, like
sharing the DXGI implementation, or using a scheme like vkd3d where
Wine's d3d11 could have optionally loaded DXVK as a regular shared
library. That e-mail went unanswered. Now, I appreciate that different
people have different ideas about what's acceptable and what isn't,
but personally I think that's extremely rude and uncivilised.
Nevertheless, e-mail gets lost sometimes, sometimes people are busy,
everyone gets a second chance. So a few months later, since I was
organising WineConf 2018, I sent Philip a personal invitation to
attend WineConf, and perhaps discuss things there. That invitation
went unanswered too, at which point I was pretty much done with DXVK.
It is my understanding that since then both Jeremy White and
CodeWeavers' partners at Valve have tried reaching out to Philip on
the subject, but evidently with little success.

Bottom line, cooperation only works if both sides are trying.

There's one more issue I'd like to address, which isn't about the
wined3d Vulkan backend—also known by its internal codename
"Damavand"—but rather about certain comments along the lines of "Wine
should accept C++ code", "Wine maintainers are mean because they
didn't accept my patch", etc. Leaving aside for the moment the fact
that none of those were the issue with DXVK, that's really not how
this works. Like any project, the Wine project has certain rules,
certain guidelines, and certain standards. Some people may disagree
with some of those, that's fine. Perhaps some people would like to see
some rules or guidelines changed, standards raised or lowered. That's
fine too, and the way to go about that would be to become a well
respected member of the Wine community, make your argument, and
perhaps if enough people find your argument convincing, it may even
happen. On the other hand, shouting from the sidelines, on the
internet, is rather unlikely to be effective. Similarly, a lot of
these rules, guidelines and standards are well known even outside the
Wine project. If you knowingly start some project that conflicts with
those, best of luck to you and we hope you have fun, but it's really
not on the Wine project if that code then doesn't end up going into
upstream Wine. And last, but not least, "Wine developers should work
on what I tell them to". No.

Anyway it's fine as long as proton can filter out the best of both world.


Last edited by minidou on 15 June 2019 at 7:34 pm UTC
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring 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!
The comments on this article are closed.