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.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
8 comments
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.
0 Likes
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.
2 Likes, Who?
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
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
0 Likes
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.
1 Likes, Who?
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.
0 Likes
Quoting: EhvisI 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?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.
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.
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
3 Likes, Who?
Quoting: 3zekielThanks!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.
0 Likes
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
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
18 Likes, Who?
Patreon
PayPal
See more from me