Dxvk: Windows support

[reyaz006]

I've seen some of the comments mentioning Windows as an unsupported platform

Windows not a supported platform for _this very reason_, there's no telling why it's broken for you. Logs look fine, there must be some software interacting with Vulkan that breaks it (fwiw, having RTSS _installed_ is enough to cause issues since the Vulkan layer for that gets loaded into _every_ Vulkan app).

What's with all the Windows bug reports lately? Many games simply will not work on Windows either due to the way they load D3D DLLs, or due to interactions with amdags/nvapi libraries.

Friendly reminder that Windows is not our primary target platform and not really supported. This problem doesn't occur on Linux.

I mean no disrespect, and I may not know a lot of stuff related to d3d/vk. But I want to state what seems obvious to me: supporting Windows platform should make a lot of sense.

I'm a Windows user, and dxvk helped me more than I hoped. There were cases where it removed the annoying stutter and solved the driver crash/hung. I imagine it should help with many older games, since new hardware and drivers can break their support at some point.

dxvk is basically a Windows DLL, and it works well in many cases on Windows. If there are games that work well with dxvk under Wine but not under Windows, surely there must be some things that can be done. Blocking amdags/nvapi libraries from applying specific stuff is the first thing that comes to mind, if they are the problem.

Maybe people will be more willing to report more issues properly if they see that Windows reports are also accepted. Maybe those reports can help finding (and fixing) more issues on Wine too. Or maybe someone decide to contribute Windows-specific fixes that can be made optional. Or maybe, if you prefer that someone else just create a fork and collect all Windows related feedback elsewhere, it might help if it's clearly stated so.

[doitsujin]

Thing is, we cannot support a platform where

• Broken third-party software like RTSS or OBS often breaks DXVK, even when not running. We can't really do an awful lot about that, and I can't really be arsed to try to remote-debug people's setup issues on a platform I'm not really familiar with in the first place.
• Games fail to the correct DLLs and end up trying to use e.g. Microsoft's DXGI with DXVK's D3D11, which obviously will not work, and which is again not something we can fix in DXVK. On Wine, DXVK essentially replaces the "system" DLLs, on Windows, you cannot do that.
• Games straight-up boot you out when they find extra DLLs next to their exe (Overwatch, Genshin Impact, probably others)
• Vulkan drivers are just not as good. Granted, this has improved a fair bit (Nvidia basically uses the same driver as on Linux anyway, but AMD's Windows driver used to be a lot worse than it is right now while we target RADV on Linux), but it still is a problem here and there and we can't just tell people to use a different driver because there only is one.
• nvapi/amdags stuff, as you mentioned. There's no way to just "block" it. If a game expects these things to work in a specific way, then they will straight-up not work. Our vendor ID workarounds are good enough to convince games to not even try to use them in many cases, but sometimes that doesn't really work as well, and no, we're not going to add weird hacks to intercept nvapi calls, that's beyond the scope of this project and would just open a whole different can of worms anyway.
• Other random issues pop up from time to time, like the Vulkan loader using DXGI to enumerate Vulkan devices, while our implementation uses Vulkan to enumerate DXGI adapters, creating a circular reference.

Using DXVK with D3D9 games on Windows is usually less problematic because these older games just tend to be happy if their D3D9 calls succeed, but things are a lot more complicated now. So, no, we cannot and will not offer any sort of official support Windows. You're free to try it, and it'll often just work, but when it doesn't, it's not our problem in the first place.

[reyaz006]

we cannot and will not offer any sort of official support Windows. You're free to try it, and it'll often just work, but when it doesn't, it's not our problem in the first place.

I'm not really asking current owners and contributors to provide support. Maybe just not closing Windows related issues, making it clear to everyone that even though there may be ways to fix their Windows issues, you are not going to do that if there are no such issues on Wine (and that someone else is free to provide such support, debugging or fixes), would be enough.

Broken third-party software like RTSS often breaks DXVK. We can't really do an awful lot about that, and I can't really be arsed to try to remote-debug people's setup issues on a platform I'm not really familiar with in the first place.

Could there be no other similar software that would break stuff on Wine too? A line of text in Readme about 3rd party software being able to break dxvk would be enough. Let users know that they should at least try disabling those and try again, before reporting issues.

Games fail to the correct DLLs and end up trying to use e.g. Microsoft's DXGI with DXVK's D3D11, which obviously will not work, and which is again not something we can fix in DXVK. On Wine, DXVK essentially replaces the "system" DLLs, on Windows, you cannot do that.

I think that's just an OS-wide security behavior (google SafeDllSearchMode) which can be disabled. Also I'm not totally sure but it still should not be enabled by default for all Windows installations.

Games straight-up boot you out when they find extra DLLs next to their exe (Overwatch, Genshin Impact, probably others)

That might be anti-cheat measures (Genshin Impact uses an anti-cheat kernel driver). If such games work on Wine after you replace system DLLs then I guess Linux/Wine is one of their target platforms.

Vulkan drivers are just not as good. Granted, this has improved a fair bit (Nvidia basically uses the same driver as on Linux anyway, but AMD's Windows driver used to be a lot worse than it is right now while we target RADV on Linux), but it still is a problem here and there and we can't just tell people to use a different driver because there only is one.

You mean they are not as good on Windows when compared to Linux? Valid point, but isn't it something that can be improved in future?

nvapi/amdags stuff, as you mentioned. There's no way to just "block" it. If a game expects these things to work in a specific way, then they will straight-up not work.

If a game expects things to work that way, wouldn't it straight-up not work on Wine either?

[mozo78]

The time has come when Windows users need to understand that they can't have everything. They will have to make sacrifices if they wish something too hard. Use Linux and you'll be fine. Anyway, Windows is rubbish.

[SveSop]

nvapi/amdags stuff, as you mentioned. There's no way to just "block" it. If a game expects these things to work in a specific way, then they will straight-up not work.

If a game expects things to work that way, wouldn't it straight-up not work on Wine either?

And most of the times it does not, so you have to do things like DXVK does - ie. "fake" another card, so that the game/app do not try to load nvapi.dll for instance. However, some apps/games are somewhat hard-coded in that they load nvapi.dll anyway and it DOES create all kinds of havoc. Hence, that is a reason why steam-proton does not compile those at all.

You can't really opt-out of installing nvapi.dll when using a nVidia card under Windows. What happens if you straight up delete the nvapi.dll from the windows system folders, i do not know... but i would not immediately recommend doing that.
Nor would i recommend deleting/replacing system d3d11.dll with dxvk ones either, cos for all you know Office 365 might just be using some d3d9/11/12 functions to display something... Then you suddenly have random non-game programs crashing/misbehaving.

Then what? Supposed DXVK should fix that too then? Nah.. i think "If it works - fine.. if not.. sorry" is the correct attitude to take, unless you have a whole team of debuggers standing by to fix various windows related issues.

[reyaz006]

And most of the times it does not, so you have to do things like DXVK does - ie. "fake" another card, so that the game/app do not try to load nvapi.dll for instance. However, some apps/games are somewhat hard-coded in that they load nvapi.dll anyway and it DOES create all kinds of havoc. Hence, that is a reason why steam-proton does not compile those at all.

What I mean is that parity between Wine and Windows should be achievable for such cases. If a sole existence of nvapi.dll is the only difference that is enough to break some games on Windows, then you shouldn't need to remove it to fix it - e.g. hooking LoadLibrary should do the same thing. And I'm not proposing current team to do this. Just let people know that someone else might be able to solve such problems, instead of going "won't fix, closing".

Then what? Supposed DXVK should fix that too then?

Supposed fork of dxvk might do. But then, maybe it will be decided (and stated) that Windows-specific contributions are welcome here.

unless you have a whole team of debuggers standing by to fix various windows related issues.

I can understand not willing to spend time on it. But don't make it sound like Windows cases are overly difficult to debug. At the very least, when it's the fault of active background 3rd party software or driver failure it should be easy to tell, even by user himself when provided with appropriate instructions.

[doitsujin]

hooking LoadLibrary should do the same thing

NO. We should NEVER hook LoadLibrary, or any other system routine, for that matter.

This is exactly the kind of crap I was talking about. Bullshit hacks that don't work half the time and would just end up making the software worse for the intended use case, which is running on Linux. We're still a D3D reimplementation, not some malware that fucks with system libraries to the point where it just ends up introducing additional problems that go beyond "looks like this game really needs nvapi to work".

But all of that is besides the point anyway. Take #1800 as an example, which mentions SotTR. That particular game runs perfectly fine on my Windows 10 setup using DXVK - there's nothing inherently stopping it from working. I've also successfully run it on an Nvidia system on Windows in the past. Yet it doesn't run on theirs. Why? No idea. Could be literally anything.

And we have better things to do than debug people's Windows setups. Working on vkd3d-proton to improve D3D12 support for example, which is a lot more useful for what we're actually trying to achieve here. It's not like the vast majority of Windows users has any good reason to use DXVK in the first place.

[reyaz006]

NO. We should NEVER hook LoadLibrary, or any other system routine, for that matter.

This is exactly the kind of crap I was talking about. Bullshit hacks that don't work half the time and would just end up making the software worse for the intended use case, which is running on Linux. We're still a D3D reimplementation, not some malware that fucks with system libraries to the point where it just ends up introducing additional problems that go beyond "looks like this game really needs nvapi to work".

Alright. This doesn't invalidate everything else I said though. Maybe a correct way to solve nvapi related issues would be to communicate with Nvidia so they'd stop doing anything with it if non-official D3D implementation is detected.

But all of that is besides the point anyway. Take #1800 as an example, which mentions SotTR. That particular game runs perfectly fine on my Windows 10 setup using DXVK - there's nothing inherently stopping it from working. I've also successfully run it on an Nvidia system on Windows in the past. Yet it doesn't run on theirs. Why? No idea. Could be literally anything.

This probably doesn't change anything but I don't think it mentions SotTR anywhere.

And we have better things to do than debug people's Windows setups.

All I'm asking for is to provide a definitive information for Windows users who would like to use dxvk or contribute - so they could understand right away what kind of interaction they could expect. If you straight up don't want to see any reports from them - you could let them know. Again, sorry for misleading title.

[doitsujin]

If you straight up don't want to see any reports from them - you could let them know.

We've had that since forever.

https://github.com/doitsujin/dxvk/wiki/Driver-support#windows-drivers