DXVK, a Vulkan-based compatibility layer for Direct3D 11 for use with Wine

This is interesting
Did not know about the D3d9 one.
Methinks more games shall run soon :)

Still quite buggy at this stage, but some games do perform well already.

I like my Blizzard games, and it seems to be more fluid using DXVK than gallium-nine on Diablo III... But there are some visual bugs that need fixing.

I tried Quantum Break also which launches but is pretty slow in game right now 10-20 fps.

I've thought about trying this with Dying Light as I can't get the native Linux version to launch.

One thing to mention is you really need to be using the latest mesa-git and radv-git drivers if you're an AMD user, I was getting some weird glitches on the stable branch.


Last edited by lejimster on 26 Mar 2018 at 9:19 am UTC

It's interesting to see what will become of this, since the Wine developers are working on their own Vulkan implementation.

If you mean that Wine people are working on their D3D-on-Vulkan implementation – that’s true, but they are not doing the same. DXVK implements D3D11 on Vulkan. Wine’s VKD3D is to implement D3D12-on-Vulkan (basically the exact reverse of what Vulkan Portability Initiative tries to achieve), and Vk9, as you wrote, is to implement D3D9-on-Vulkan.

Three projects, and every one of them tries to implement a different version of D3D API.

I only wonder if Windows applications can call to multiple D3D versions simultanuously to draw on the same context, and if so, how it can be handled by such projects (does D3D11 implementation have to implement D3D9 and everything below too?). And if so, can all the D3Dx-on-Vulkan projects share code? As I have almost no experience with GPU programming and absolutely none with DirectX, I have no idea – but it’s something that, in my not educated enough mind, seems like a potential problem.


Last edited by silmeth on 26 Mar 2018 at 9:25 am UTC

Any chance this will get included in the wine-staging project? so far it seams a pain in the ass to install as it is.

Installing DXVK is pretty easy. It’s just pasting two dlls to wine prefix / application directory and setting library overrides in wine.

The problematic part is not directly related to DXVK – it is setting up Vulkan support in Wine itself (which needs Windows Vulkan SDK installed and set up). I think with time Wine will handle it somehow more automatically (probably like installing Gecko and Mono?), but for now they did not figure out how to do it properly.


Last edited by silmeth on 26 Mar 2018 at 10:27 am UTC

Still quite buggy at this stage, but some games do perform well already.

I like my Blizzard games, and it seems to be more fluid using DXVK than gallium-nine on Diablo III... But there are some visual bugs that need fixing.

I tried Quantum Break also which launches but is pretty slow in game right now 10-20 fps.

I've thought about trying this with Dying Light as I can't get the native Linux version to launch.

One thing to mention is you really need to be using the latest mesa-git and radv-git drivers if you're an AMD user, I was getting some weird glitches on the stable branch.

I can run Dying Light native without problems on Nvidia binary. If you are a Mesa user , you must force OGL version to 4.5 via launch options.

Three projects, and every one of them tries to implement a different version of D3D API.

True enough, I would have thought the Wine developers would eventually move to do more with Vulkan, but perhaps if they integrate stuff like this when it's more mature they won't need to themselves for other parts of D3D.

I've thought about trying this with Dying Light as I can't get the native Linux version to launch.

Hello fellow vega 56 user!
Just force the gl version:
MESA_GL_VERSION_OVERRIDE=4.4 MESA_GLSL_VERSION_OVERRIDE=440 %command%

:)

I've thought about trying this with Dying Light as I can't get the native Linux version to launch.

Hello fellow vega 56 user!
Just force the gl version:
MESA_GL_VERSION_OVERRIDE=4.4 MESA_GLSL_VERSION_OVERRIDE=440 %command%

:)

I need to try this tonight as currently nothing happens. Sometimes I'll get the splash box but then it immediately crashes.


Last edited by drlamb on 26 Mar 2018 at 12:35 pm UTC

dxvk had amazing progress. Some features though are quite hard to implement, such as stream output, because Vulkan lacks comparable functionality. So that's still in the TODO list.

Overall performance is very good, unlike with wined3d which now currently is bugged by buffer mapping issues (but Wine developers are working on it).

For TW3, in the wilderness, dxvk gives 65+fps:

In areas with many NPCs, it gives 55+fps:

That's without vsync, 1920x1200, Vega 56 8GB VRAM.


Last edited by Shmerl on 26 Mar 2018 at 1:15 pm UTC

I can run Dying Light native without problems on Nvidia binary. If you are a Mesa user , you must force OGL version to 4.5 via launch options.

I've thought about trying this with Dying Light as I can't get the native Linux version to launch.

Hello fellow vega 56 user!
Just force the gl version:
MESA_GL_VERSION_OVERRIDE=4.4 MESA_GLSL_VERSION_OVERRIDE=440 %command%

:)

Thanks, but I guess I should have been more specific. It appears to be an Arch issue that only effects Mesa users. I think some other distros suffer the same problem. I tried for hours different work arounds, even following GloriousEggroll's snap package guide and it still wouldn't launch :'(.

I can run Dying Light native without problems on Nvidia binary. If you are a Mesa user , you must force OGL version to 4.5 via launch options.

I've thought about trying this with Dying Light as I can't get the native Linux version to launch.

Hello fellow vega 56 user!
Just force the gl version:
MESA_GL_VERSION_OVERRIDE=4.4 MESA_GLSL_VERSION_OVERRIDE=440 %command%

:)

Thanks, but I guess I should have been more specific. It appears to be an Arch issue that only effects Mesa users. I think some other distros suffer the same problem. I tried for hours different work arounds, even following GloriousEggroll's snap package guide and it still wouldn't launch :'(.

Interesting. I had no issues on arch when I tried it a month or so ago. What exactly is the issue?

I can run Dying Light native without problems on Nvidia binary. If you are a Mesa user , you must force OGL version to 4.5 via launch options.

I've thought about trying this with Dying Light as I can't get the native Linux version to launch.

Hello fellow vega 56 user!
Just force the gl version:
MESA_GL_VERSION_OVERRIDE=4.4 MESA_GLSL_VERSION_OVERRIDE=440 %command%

:)

Thanks, but I guess I should have been more specific. It appears to be an Arch issue that only effects Mesa users. I think some other distros suffer the same problem. I tried for hours different work arounds, even following GloriousEggroll's snap package guide and it still wouldn't launch :'(.

Interesting. I had no issues on arch when I tried it a month or so ago. What exactly is the issue?

I get a black screen with white loading bar at the bottom, it fills up and then crashes out.

Log file always goes something like this..

{14:41:30.422} INFO: [INFO] > Caught signal 11 (Segmentation fault).
{14:41:30.426} INFO: [INFO] > /usr/lib/libc.so.6(+0x348e0) [0x7f6ce555a8e0]
{14:41:30.426} INFO: [INFO] | libengine.so(_ZN12CTextManager10InitializeEv+0x26f) [0x7f6ce6fc78ff]
{14:41:30.426} INFO: [INFO] | libengine.so(_Z13CreateTextMgrv+0x40) [0x7f6ce6fc7a50]
{14:41:30.426} INFO: [INFO] | libengine.so(_ZN9CRenderer13LoadResourcesEv+0x2c) [0x7f6ce6fb50bc]
{14:41:30.426} INFO: [INFO] | libengine.so(_ZN5CGame10InitializeEPciPvS1_jjP18IProgressIndicator+0x2370) [0x7f6ce6a8e5b0]
{14:41:30.426} INFO: [INFO] | /mnt/Data/Steam/SteamLibrary/steamapps/common/Dying Light/DyingLightGame(main+0xa45) [0x43e315]
{14:41:30.426} INFO: [INFO] | /usr/lib/libc.so.6(__libc_start_main+0xea) [0x7f6ce5546f4a]
{14:41:30.426} INFO: [INFO] | /mnt/Data/Steam/SteamLibrary/steamapps/common/Dying Light/DyingLightGame() [0x4425d9]

Thanks, but I guess I should have been more specific. It appears to be an Arch issue that only effects Mesa users. I think some other distros suffer the same problem. I tried for hours different work arounds, even following GloriousEggroll's snap package guide and it still wouldn't launch :'(.

FYI there's a long thread in the forums about this problem. You guys might want to move the conversation there to keep this one on topic.

This is interesting
Did not know about the D3d9 one.
Methinks more games shall run soon :)

Definitely! The question is: What do we do about it? The more Windows titles work with Wine, the less people want to wait for a native version, the less will ask for one, the less demand for Linux games will be seen on Steam.
Wine gamers will get no support for their platform, but count as Windows users. I think we should always be aware of that.

Definitely! The question is: What do we do about it? The more Windows titles work with Wine, the less people want to wait for a native version, the less will ask for one, the less demand for Linux games will be seen on Steam.
Wine gamers will get no support for their platform, but count as Windows users. I think we should always be aware of that.

This was discussed at length already. Linux games (I assume you mean native Linux games) depend on engines support for Linux, and engines support is improving quite well, regardless of Wine. Case in point - Unreal, Unity, Cry, Nitrous and etc. So amount of native Linux games is growing healthily.

The only ones who are pressured by Wine competitively, are other wrapper developers such as Feral and VirtualProgramming. They'll have to cope with competition and adapt their approach. For example by open sourcing their own wrappers.


Last edited by Shmerl on 26 Mar 2018 at 2:52 pm UTC

Definitely! The question is: What do we do about it? The more Windows titles work with Wine, the less people want to wait for a native version, the less will ask for one, the less demand for Linux games will be seen on Steam.
Wine gamers will get no support for their platform, but count as Windows users. I think we should always be aware of that.

This was discussed at length already. Linux games (I assume you mean native Linux games) depend on engines support for Linux, and engines support is improving quite well, regardless of Wine. Case in point - Unreal, Unity, Cry, Nitrous and etc. So amount of native Linux games is growing healthily.

The only ones who are pressured by Wine competitively, are other wrapper developers such as Feral and VirtualProgramming. They'll have to cope with competition and adapt their approach. For example by open sourcing their own wrappers.

There are already developers saying they can't deliver a Linux version, but hey, the game works on Wine, why don't you just use that instead? There will be more of those in the future, PLUS Feral and Aspire have harder times porting native Versions.

There are already developers saying they can't deliver a Linux version, but hey, the game works on Wine, why don't you just use that instead? There will be more of those in the future, PLUS Feral and Aspire have harder times porting native Versions.

There are also developers who always claimed they can't support Linux version because they have no time / resources / etc. Wine doesn't change their attitude, they simply don't want to support it.

Wine as an excuse is quite silly, if their own engine supports Linux natively. It's simply rephrasing their "we have no resources for it". How would they have gotten more resources, if Wine wouldn't have existed?


Last edited by Shmerl on 26 Mar 2018 at 3:16 pm UTC

There are already developers saying they can't deliver a Linux version, but hey, the game works on Wine, why don't you just use that instead? There will be more of those in the future, PLUS Feral and Aspire have harder times porting native Versions.

There are also developers who always claimed they can't support Linux version because they have no time / resources / etc. Wine doesn't change their attitude, they simply don't want to support it.

It's just not my point. Linux is the last open gaming platform to be. While it is good to have most games playable on Linux, it is essential to have most of them natively on Linux, because otherwise no one will see a Linux market anymore. Therefore I am not concerned about developers that hate Linux, but about the others to stop native Linux versions, because it's cheaper for them to just point at Wine.

It's just not my point. Linux is the last open gaming platform to be. While it is good to have most games playable on Linux, it is essential to have most of them natively on Linux, because otherwise no one will see a Linux market anymore.

Again, this is addressed with engines, Wine has no impact on that. Wine only impacts wrapped games market. So far I don't see any indication of native engines support for Linux slowing down because of Wine progress.


Last edited by Shmerl on 26 Mar 2018 at 3:27 pm UTC

There are already developers saying they can't deliver a Linux version, but hey, the game works on Wine, why don't you just use that instead? There will be more of those in the future, PLUS Feral and Aspire have harder times porting native Versions.

There are also developers who always claimed they can't support Linux version because they have no time / resources / etc. Wine doesn't change their attitude, they simply don't want to support it.

Wine as an excuse is quite silly, if their own engine supports Linux natively. It's simply rephrasing their "we have no resources for it". How would they have gotten more resources, if Wine wouldn't have existed?

It's easy to say you don't have the resources, even if you had them...
And again, every Linux user purchasing a Windows game for Wine, that still has a chance for a native Linux version, is a -1 for Linux statement.


Last edited by Nevertheless on 26 Mar 2018 at 6:43 pm UTC