Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone. Just good, fresh content! Alternatively, you can donate through PayPal. You can also buy games using our partner links for GOG and Humble Store.
We do often include affiliate links to earn us some pennies. See more here.

Direct3D 9-10-11 to Vulkan translation layer DXVK 1.8.1 is out now

By - | Views: 22,454

After the 1.8 release of DXVK on February 19, a small 1.8.1 release just went out for this Direct3D 9-10-11 to Vulkan translation layer. DXVK is usually used for the Wine and Proton compatibility layers for running Windows games on Linux.

Quite a short and sweet release this one with no major new features, instead there's some nice bug fixes and improvements. Here's the release notes:

  • Fixed a regression that would cause a number of D3D9 games to crash when changing the resolution or during startup.
  • Fixed a regression causing black textures in some D3D9 games (#1947)
  • Improved performance in many D3D9 games when using MSAA on RADV.
  • Improved presentation logic for MSAA swap chains, which are common in older D3D9 games.
  • Mafia II: Work around shadows being broken when the game thinks it's running on an AMD GPU.
  • Warhammer Online: Work around the game trying to use unsupported image formats. (#1296)

If you missed it - Portal 2 was recently upgraded and now has DXVK giving it Vulkan support. It's not just used for Wine and Steam Play Proton, as it can be built as a native library for developers to use.


As a reminder: if you're making use of Steam Play Proton which includes DXVK - you can upgrade this by itself, without waiting for a new Proton release. To do so you can just overwrite the existing DXVK files with the release download of DXVK 1.8.1. You can find your Proton install somewhere like this (depending on your Steam Library drives):

path-to-your/SteamLibrary/steamapps/common/Proton x.x/dist

Where x.x is whatever Proton version installed you wish to give a new DXVK.

Inside there you will see "lib" and "lib64", for 32bit and 64bit. Inside each of those, there's a "wine" folder and inside there is a "dxvk" folder and that's where you replace the files with new versions. Do so at your own risk but it's usually harmless. If you mess anything up, one way to ensure it gets reinstalled cleanly is just to remove the "/dist" folder.

Article taken from GamingOnLinux.com.
Tags: Open Source, Vulkan, Wine | Apps: DXVK
23 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.
8 comments

BielFPs Mar 1, 2021
QuoteMafia II: Work around shadows being broken when the game thinks it's running on an AMD GPU.

This make me thing if developers didn't mad the game to break something on AMD hardware on purpose, in order to make Nvidia cards look better.

I hope it's not the case here, but I vaguely remember AMD accusing Nvidia to do this with some games many years ago.
Ehvis Mar 1, 2021
View PC info
  • Supporter Plus
Quoting: BielFPs[This make me thing if developers didn't mad the game to break something on AMD hardware on purpose, in order to make Nvidia cards look better.

Or they did it to fix something that broke on the amd driver. And since Linux drivers have nothing in common, it didn't need that fix.

You can always go with the conspiracy theory. But you'll almost always be wrong.
kokoko3k Mar 1, 2021
Anubody could explain me if (and why) using DXVK as a native library could lead to better performance?
Is it the same as using it via .so and not .dll in wine itself?
I've tried and that way the performance are unchanged.


Last edited by kokoko3k on 1 March 2021 at 7:44 pm UTC
3zekiel Mar 1, 2021
Quoting: kokoko3kAnubody could explain me if (and why) using DXVK as a native library could lead to better performance?
Is it the same as using it via .so and not .dll in wine itself?
I've tried and that way the performance are unchanged.

If you use the lib natively, as in inlining within your code, the compiler can inline many calls, and thus reduce overhead. Overall, the compiler will of course have much more flexibility for optimization. Also, avoiding indirect calls in general is very useful in term of performance.
If you build it as a shared library, you will still avoid the pe loader, and I expect some needless syscall translation. You should also avoid all sync primitives translation issues you would usually have to deal with between losedow$s API and posix API.
I would expect it won't affect average framerate much, but min framerate should take a small boost, especially on more limited configurations.
Xpander Mar 1, 2021
Quoting: BielFPsThis make me thing if developers didn't mad the game to break something on AMD hardware on purpose, in order to make Nvidia cards look better.

I hope it's not the case here, but I vaguely remember AMD accusing Nvidia to do this with some games many years ago.

The Warhammer Online issue that got closed is similar to this. The game takes different path when checking what GPU you have. Only nvidia hardware supports that image format, but thats only available on the windows drivers is my understanding. Not implemented in DXVK. Faking the GPU to AMD takes the different path and all is fine. Older dx9 games seems to have loads of similar things taking different paths of different GPU vendors. Nothing new here.
Purple Library Guy Mar 1, 2021
Quoting: Ehvis
Quoting: BielFPs[This make me thing if developers didn't mad the game to break something on AMD hardware on purpose, in order to make Nvidia cards look better.

Or they did it to fix something that broke on the amd driver. And since Linux drivers have nothing in common, it didn't need that fix.

You can always go with the conspiracy theory. But you'll almost always be wrong.
I doubt it was done with deliberate ill intent, but that seems kind of backwards. I mean, if it works OK on AMD as long as the game doesn't know it's on AMD, but breaks if it does know, how can it have been fixing something on AMD?

Side note: The problem with most conspiracy theories is not that there's a conspiracy involved.
Spoiler, click me
There are plenty of real conspiracies. Microsoft conspired to tweak Windows in such a way as to stop Lotus 1-2-3 from running, so they'd be able to sell Excel. ExxonMobil conspired for decades to secretly create propaganda (which they knew was false) to the effect that anthropogenic climate change was fake, because they feared that if people believed it was real and started trying to do something about it, that would kill their massive billions in profits. They were very likely correct. Little happened to them when it came out because lying propgaganda campaigns aren't actually illegal, so it was low risk. Etc etc etc; there are tons of these.

Real conspiracies are almost always about profit, and are generally done by a fairly tight-knit entity with few outsiders "in the know". So OK, this NVidia idea would be about profit (nobble the competition), but it would require getting co-operation from game developers, who fundamentally would prefer their games run well on all customers' computers. That would require bribing them . . . all in all, it seems illegal and with a high risk someone would blab, because it needs all those "outsider" game developers for it to work. On balance not a very likely conspiracy IMO; I'd want to see quite a bit of evidence before I started worrying about it.

Stupid conspiracy theories are ones where the motivation is bizarre (so . . . they're doing X Y Z because . . . they want to drink children's blood? Whatever!) or the supposed group is extensive and varied (The A are teaming up with the B and the Q even though they have no reason to trust or share spoils with each other, would normally be expected to have motivations at odds, and there's no possible way a group that big could keep a secret). Bonus stupidity points if there's no obvious organizational framework to keep the conspiring entities pointing in one direction. Extra-bonus stupidity points if the conspiracy supposedly uses some organization, but works systematically counter to the interests of the actual main funders of the organization--eg most United Nations conspiracy theories.


Last edited by Purple Library Guy on 1 March 2021 at 9:15 pm UTC
kokoko3k Mar 1, 2021
Quoting: 3zekiel
Quoting: kokoko3kAnubody could explain me if (and why) using DXVK as a native library could lead to better performance?
Is it the same as using it via .so and not .dll in wine itself?
I've tried and that way the performance are unchanged.

If you use the lib natively, as in inlining within your code, the compiler can inline many calls, and thus reduce overhead. Overall, the compiler will of course have much more flexibility for optimization. Also, avoiding indirect calls in general is very useful in term of performance.
If you build it as a shared library, you will still avoid the pe loader, and I expect some needless syscall translation. You should also avoid all sync primitives translation issues you would usually have to deal with between losedow$s API and posix API.
I would expect it won't affect average framerate much, but min framerate should take a small boost, especially on more limited configurations.
Thanks!
YoRHa-2B Mar 1, 2021
I haven't debugged the Mafia II issue so no idea what's going wrong there, but D3D9 games tend to make a lot of assumptions about driver behaviour based on the reported GPU/vendor/feature set, which might have been correct on 2010 drivers from said vendor, but don't necessarily hold true on DXVK or sometimes even current hardware/Windows drivers.

There are games (cough Sims 2) that are literally broken on GPUs less than 15 years old, and that is on Windows, and contain broken code paths that can be triggered if you report specific features as supported when the game doesn't expect it, etc. Others will literally just crash on start if they can't find a DLL starting with "ati" or "nvd", because apparently there's no way that vendors will ever rename their driver DLLs. The sheer amount of bullshit you have to work around to make D3D9 games happy is ludicrous.

And it doesn't get any better once you start looking at dumb shit games do that shouldn't work but somehow does anyway, like unlocking a resource (i.e. telling the driver that the game no longer needs CPU access to the resource) and then proceeding to do all sorts of CPU access anyway, writing to a read-only resource, etc. If anyone ever wondered why we're still having so many bugs and performance issues with D3D9, here you are.


Last edited by YoRHa-2B on 1 March 2021 at 11:49 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.