Dxvk: DXVK replaces dxgi.dll, what does it mean for vkd3d?

[kakra]

If I enabled dxvk, this replaces dxgi. What does this mean for d3d12 support in games, or especially, how would it affect usage of vkd3d? Is it possible to use both in parallel at "the same time"? (read: via Proton or for different games in the same wine prefix)

[doitsujin]

Currently, no, but it should be possible for DXVK to support vkd3d in the future since it only requires modification to the swap chain code as far as I'm aware.

The other way around would be a much bigger issue because DXVK's DXGI is designed around Vulkan whereas wine's DXGI isn't, and instead lets vkd3d do all the Vulkan instance and device creation stuff.

Also, please don't try to tag your issues, it makes the title look ugly.

[steemandlinux]

Games cannot use both DX11 and DX12 at the same time.

[kakra]

@steemandlinux Actually, this question is not about using them in parallel within the same game but in parallel within the same wine prefix for different games. With upcoming DX12 titles, Proton would need to be tuned individually per game to either use DXVK or wined3d then. I think we should think about a somewhat more automatic solution.

UPDATE: Amended my question to better explain what is meant.

[kakra]

@doitsujin Would this mean that DXVK would be linked against vkd3d in the future plus adding the needed swapchain code? That would effectively result in DXVK supporting DX12 then, correct? I like this approach.

[bobwya]

@kakra

Wine supports per-app dll overrides.
See: WineHQ Wiki: Useful Registry Keys (AppDefaults)
Just override the dxvk dll's for game binaries you want to pass through dxvk vs the builtin Wine implementation.
So would this not work already?

[kakra]

@bobwya Yes, this is fine for single wine prefixes. But Proton creates one prefix per game. It would need to ship defaults for every game then.

[setsunati]

Would be great i think if vkd3d and vk9 merges with dxvk sometime in future, this way we will have d3d9 to d3d12 support all in one place.

[tingvarsson]

@kakra think you misunderstood @bobwya.
What wine can do, and he is stating, is per-app overrides. That is different overrides per application within one prefix.

And what is also possible is overrides per execution, which is what Proton is using today. E.g. dxvk is not configured in the prefix but at "runtime", before start of whatever game.

[doitsujin]

@tingvarsson i'm not really sure if that's really a desireable solution. Most Dx12 games have a Dx11 renderer as well, and there may be good reasons to prefer one over the other on specific configurations, but by using wine's built-in DXGI DLL you'd lock out DXVK, and by using DXVK's DXGI you'd lock out vkd3d.

So yeah, the best solution would be to just enhance compatibility, and considering how vkd3d is designed, it appears that supporting it inside dxvk would be much easier than adding dxvk support to wine's dxgi. Not really sure how well interop would work out though, but maybe we won't need it.

[tingvarsson]

@doitsujin wasnt arguing for one or the other actually. just trying to clarify the facts of what had been said already.
But are you saying they are using the dx11 and 12 at the same time?! or you just mean that it is possible to run with either?
If it is the later, then it would still be possible to have different overrides at runtime as Proton does it to achieve the two scenarios.

Regardless I do agree with you, a solution working together from scratch is optimal. Less hacks, less things that can go wrong.

[doitsujin]

or you just mean that it is possible to run with either?

That. D3D11 is usually the default option (with Shadow of the Tomb Raider being a notable exception).

If it is the later, then it would still be possible to have different overrides at runtime as Proton does it to achieve the two scenarios.

Yes, but it's stupidly inconvenient since you cannot just use the ingame option to switch between them, no, you'd have to do it externally.

[kakra]

@tingvarsson wrote:

@kakra think you misunderstood @bobwya.
What wine can do, and he is stating, is per-app overrides. That is different overrides per application within one prefix.

And what is also possible is overrides per execution, which is what Proton is using today. E.g. dxvk is not configured in the prefix but at "runtime", before start of whatever game.

Yes, I totally understand it. But in Proton you have one option to either use DXVK throughout your Steam lib, or not using DXVK, or even disable DX11 completely.

This way, I'm not able to easily run DX12 title because I'd had to switch off DXVK first. But when I did this, I could no longer properly run a lot of DX11 titles.

If DXVK would just wrap vkd3d into its own DXGI, it would become much more convenient and many games could work out of the box with either renderer.

As @doitsujin already pointed out:

If it is the later, then it would still be possible to have different overrides at runtime as Proton does it to achieve the two scenarios.

Yes, but it's stupidly inconvenient since you cannot just use the ingame option to switch between them, no, you'd have to do it externally.

I don't want to adjust start options per game all the time. It should just work out of the box. I think Valve wants some solution that also works for Joe Average. You know how to tinker with per-app overrides, I know it. But it's inconvenient and not suited for said Joe Average (or even Jane Average to prevent a forthcoming gender discussion).

And I don't think @doitsujin wants to reimplement in DXVK what vkd3d could already do just fine with appropriate performance. So, if it just needs a thin DXGI wrapper to make this happen, let's do it?

[SveSop]

The ideal solution would ofc be to have "one dxgi to rule them all", but keeping up with the wine teams dxgi tweaking + dxvk's own things would be somewhat of a pita i guess :)
Some crafty person come up with a patch for wine-staging that would make "dxgi-version" selectable from the staging tab in winecfg perhaps? :) Kinda like the same way the csmt patch was done pre 3.0? (Don't remember atm, but i think staging had a patch that made you able to kinda rename dll's.. ie you would have dxgi-dxvk.dll, dxgi-wine.dll and so on)

@kakra Are you saying you are able to run a dx12 title with steam + proton as of now? What game? I cant get vkd3d to do a simple triangle test without segfaulting, so i would love to hear a dx12 title to test :)

[kakra]

@kakra Are you saying you are able to run a dx12 title with steam + proton as of now? What game? I cant get vkd3d to do a simple triangle test without segfaulting, so i would love to hear a dx12 title to test :)

Not yet, this is brain storming here... ;-)

But I'm preparing to tinker around with that.

[SveSop]

The "winecfg approach" i had as a brainfart before i went to bed yesterday does not solve the issue of "easy configureable switchable thingy".

Now, the old wine-staging (2.x) had something called "DLL Redirects". Not sure if that works with current wine-staging, or if it was removed when staging "died"?
https://github.com/wine-compholio/wine-staging/wiki/DLL-Redirects
Could this be somewhat implemented to work the same way as "per-app dll overrides"? So you could infact have d3d11-dxvk.dll +++ redirects on a per-app basis? If so.. It COULD be a interesting idea, as dxvk dll's would be used for those apps/progs that is set up with this (and this can all be accomplished with simple .reg imports)

[neVERberleRfellerER]

@SveSop DLL redirects still work with current wine-staging and it how gallium nine is used with wine: it is used to redirect d3d9.dll to d3d9-nine.dll. It can also redirect to absolute Windows path and what you propose at least used to work (and it probably still works; I used it to redirect d3d11 to C:\dxvkd3d11.dll and so on).
UPDATE:
To the second part: it can be used on per-app basis by setting redirects in
HKEY_CURRENT_USER\Software\Wine\AppDefaults\<game>.exe\DllRedirects

[SveSop]

@neVERberleRfellerER Very nice!
Then i guess @kakra 's problem could be solved with this? Ie. a simple regfile that does the DLLRedirect + DLLOverride on a per app basis.. No need to do cumbersome switches between wined3d(vkd3d) and dxvk :)

Now.. the "lets change dx version ingame" would be a different story....

[kakra]

@SveSop et al... Guys, I'm not sure if you ever used Proton yet. I never would have asked the question if I wanted to use per app dll redirects. I know all this and know how it works.

The question is still: How would you integrate this with Proton/Steam without requiring the user to touch the configuration per game? It should work out of the box: Game wants DX12? Use it, works? Currently, it doesn't because Proton enables DX11 through DXVK as a global option (and only that, it even doesn't symlink the required DX10 bits). Turn that off and the behavior switches for all games. Because Proton works the way it works (and uses environment-injected dll overrides) it is not possible to properly/easily do a per-app configuration that "does not s**k"...

Actually, there's nothing like per-app configuration in Proton because Proton already does a per-app prefix. It moves the scope of this per-app-thingy completely out of focus. What is possible and makes the per-app scope, is to configure each game individually by editing the "startup options" per game. I also know this.

But this is not the solution I am asking for. The majority of targeted people for SteamPlay probably doesn't want to manually edit per-game start options to make something work (or break). I'm pretty sure Valve didn't create SteamPlay for a small group of tech-savvy people who are comfortable with editing and tweaking options. There's a bigger plan in the background and it should "just work". There's more behind it than Valve just being a cool Linux-oriented company. This is also about money and the safety of the company in a future with Microsoft's ongoing attempts to push vendor lock-in. There's peoples life and income behind this. Valve has liabilities here, and Valve has a business plan, it wants to grow, it wants to stay independent. I also think that this technology could become part of a game streaming platform that is not dependent on MS technology (and such a thing would currently be a pretty unique selling point).

This is also not a question about what can be done right now. I know what is possible now, I know how to do all this tweaking and manual adjustments. Actually, I'm working on a personal proton branch (or more precisely the wine-part of it) rebased to current wine with additional patches and performance tweaks (sometimes somewhat experimental but also tailored towards fixing specific problems), also adding some additional fresh source code patches by me which I want to suggest upstream (and did, like the fshack changes for compositors).

This question is here to start ideas about how to make this work better in the future.

[SveSop]

@kakra Well.. is Proton kind of something like CrossOver? "Built-on-wine-but-with-custom-patches-and-gui" ? :)

I agree that it should be completely automagically without needing to know how to click a box with "advanced settings". So, why does not Proton have a set of env variables on a "per game" basis?

[kakra]

Proton is the driving layer below SteamPlay. So let's start with SteamPlay: That's a new feature in Linux Steam that allows you do download any Windows game right into your Linux Steam library. Actually, you could also just mount your Windows Steam library in the Linux client. Buying Windows-only games from the Linux Steam client will also count as a Linux purchase now.

SteamPlay then uses Proton to start the game. Proton is actually a compatibility layer built around wine. It bundles several libraries, notably a minimal Steam API DLL which passes API calls up to the Linux Steam client from within the Wine prefix. The game thinks it's talking to Windows Steam but there is no Windows Steam client installed. It also bundles some other software to provide better compatibility: DXVK, openvr, openal-soft/ffmpeg4 (for better xaudio2 support), and some more. See here:

https://github.com/ValveSoftware/Proton

It also has a lot of fullscreen hacks to allow games switching fullscreen/windowed or setting different resolutions without actually switching your Xorg server resolution (which was always a major headache). This is done by exploiting scaling shaders of modern graphic cards. Actually, the game is drawn onto a so-called surface, and the Proton patches modify this to be stretched to fill the screen. In reality, it's a bit more complicated but essentially that is what it does. It also handles minimizing/restoring windows better than original wine. The result is that you are no longer forced to use virtual wine desktops for some games: They run as a native window.

Proton also removes a lot of UX-disturbing functions from wine, like auto-installing mono or gecko, or showing these very common debug error dialogs. Due to all these patches, Proton is not meant to be used as a standalone wine version, especially since it redirects Steam API calls and modifies handling of user profile directories. Many of the patches for Proton are flowing back into wine (as you may have noticed, there have been huge jumps of progress in wine during the last months), but some patches are really hacks which will never make it into official wine, and as such are also not suited to be used in stand-alone wine.

When you start your Linux Steam client and select to run a Windows only game, Proton will kick in. Proton sets up a wine prefix specific to the game, installs DXVK into it, fakes a Windows Steam installation by putting the Steam API DLL into place, and finally runs the game - as if it were a native Linux game.

So yes, there's actually a GUI: That is the Linux Steam client. The "advanced settings" would be to go to the start options of a game and put "SOME_CONFIG=xyz %command%" there. You could turn off DXVK that way. But you'd have to do it individually for each game. The other way is to edit a default configuration file user_settings.py and put global defaults there. But there is no way for Steam to automagically know if you would like to use DX12 or DX11 for a game. And I don't think that Valve wants to maintain a database for that (it would always be out-of-date per definition, and it could not support the case where a game could use either DX11 or DX12). So, the best way would be to have a DXVK which could also interface to vkd3d somehow. Then there's no worry which DX version you want to use. The already existing choice remains: Either prefer DXVK, or don't, globally, period.

[SveSop]

What if the case is a DX9 game? Then DXVK would have the exact same "problem".

I think that if this is supposed to be a "work out of the box" kind of thing, the steam client needs to have a set of configs that come along with the install (or Proton).

What happens today if you install a game that requires a higher DX version than you have? You could get a refund i guess... or you would have to do some manual tweaking... I dunno :(

[doitsujin]

DX9 typically doesn't interact with DXGI., unlike 10/11/12 (yes I know there are some interfaces to mix them, but it's restricted to Windows Vista and newer and therefore not overly popular).

[kakra]

I think modes like "DirectX 9ex" are such a feature? This is a mode in PoE which uses parts of DX10 but is primarily DX9.

[shmerl]

@kakra

It also has a lot of fullscreen hacks to allow games switching fullscreen/windowed or setting different resolutions without actually switching your Xorg server resolution (which was always a major headache). This is done by exploiting scaling shaders of modern graphic cards. Actually, the game is drawn onto a so-called surface, and the Proton patches modify this to be stretched to fill the screen. In reality, it's a bit more complicated but essentially that is what it does. It also handles minimizing/restoring windows better than original wine.

Sorry for off-topic, but is Wine interested in upstreaming these features?

[kakra]

@kakra I think it wasn't even considered asking this because it is hacky in a lot of places - or even very wrong as a common solution (because it doesn't switch the resolution, it only stretches the window, thus other non-fullscreen windows would not be scaled correctly compared to that).

But I think the minimizing/restore fixes could bubble up to wine upstream...

[SveSop]

Seeing as "wine" is going to continue to be its own project regardless of proton (that one might argue is a contender to crossover perhaps?), i dont think "hacky code" is going to be implemented in wine anytime soon :)

[kakra]

Crossover is made by CodeWeavers. And big parts that make up Proton are made by CodeWeavers, and thus many of Proton stuff is also going into Wine. Proton is supposed to just contain the hacky stuff of wine, I believe.

[SveSop]

Yeah. I kinda think the "vision" behind Crossover is to be compatible and stable with things like MS Office and more "corporate stuff" maybe?
Wine is then the foundation of this - and many wine devs is CodeWeaver employees :)
Proton i guess would then be "gaming for private folks" version - Wrapped together with Steam in a game-earning-business.

Something like that :)

[oscarbg]

@doitsujin +1 for supporting VKD3D under DXVK's DXGI.. I have "ported" VKD3D to Windows creating a VS2017 project in the interest of trying to add some features to VKD3D like HDR support just for fun.. but getting Wine's DXGI.dll to compile under VS2017 requires a lot of dependencies and seems a lot of work.. as DXVK supports more or less Windows compilation under VS2017 once/if DXVK supports VKD3D would be possible to develop new features to VKD3D from Windows side (using VS2017 IDE)..

[doitsujin]

Just a quick note that I started working on updating some of the DXGI stuff in the dxgi1_4 branch. DXGI 1.4 is a minimum requirement for d3d12 support.

@oscarbg DXVK might not be able to support vkd3d in MinGW/Windows builds, it's probably going to be winelib only (and therefore, Linux only).

[oscarbg]

@doitsujin thanks for your great work as always! No problem, I will take care of building DXVK+VKD3D from VS on Windows and contribute back VKD3D Win build changes eventually..

[doitsujin]

The wip-vkd3d branch implements a D3D12 presenter, which allows vkd3d's own demos to run, as well as some other tech demos.

DXVK must be compiled with winelib. MinGW builds will not work.

[SteveEbey73742]

@doitsujin, would the wip-vkd3d branch allow me to run DX12 in WoW with DXVK? if so, could you tell me how to compile the wip-vkd3d branch?

[doitsujin]

No, WoW does not work, and I'm not sure if it ever will because there are some very strange things going on related to DLL loading and D3D12 detection (e.g. when running with DXVK, WoW doesn't even try to use DXGI 1.4 despite it being available, and when compiling DXVK with winelib, D3D11 doesn't work). If you want to play WoW with D3D12, just don't use DXVK.

[SveSop]

@SteveEbey73742 Atm WoW needs some weird hacks to work with a DXVK winelib build, even for D3D11.

I have posted some tests from this https://github.com/doitsujin/dxvk/issues/706#issuecomment-437578298 , but am not able to resolve the issue.

I suspect the reason COULD have something to do with WoW's "Warden" cheat-protection or something that might need some weird support to do this loadlibrary function, but that is just a theory. (Found some vague references to "loadlibrary problems" on a couple of sites discussing WoW hacks and warden detection and such)

I don't know if other games have this behaviour either, and from what i gather Steam Proton 3.16-4 builds dxvk with mingw-w64, and not winelib, so it might not be extensively tested there either perhaps?

[doitsujin]

As of 1e393bf24d2e7a59f918e40e7e51cb676bfdfa10 and using latest wine-git, dxvk can be used with wine's DXGI DLL so that only d3d11.dll is needed.

Please keep in mind that this makes some DXGI-related config options impossible to use (e.g. spoofing different GPUs or overriding reported video memory), but it should no longer interfere with vkd3d.