Originally posted by ssorgatem
View Post
Announcement
Collapse
No announcement yet.
DXVK Is Making Significant Progress In Implementing Direct3D 11 Over Vulkan
Collapse
X
-
Originally posted by Dukenukemx View Post
How does one install DXVK?
Follow the instructions build from source. Please note at this time DXVK is taking the path of building a windows .dll file using mingw compiler so is install-able like other items in wine-tricks. Of course when reporting bugs to wine make sure you have tested without DXVK incase the bug report should be going to DXVK not wine.
In dxvk current form when it gets more mature in the sense of has a binary provide somewhere it could request to be added to winetricks .
It is one of the common problems people go nuts with winetricks not understand at times locking to X version of a dll will in fact reduce you compatibility with applications. Wine own dll implementations attempt to be a compilation of every dll that had that exact name and location. So winetricks breaking test-suite is expected. Breaking test-suite when attempting main-line merge is no go.
Most of the vulkan implementations of direct x other than mainline for direct x12 to Vulcan do appear to be following methods that will be winetricks compatible at first so giving them a lot lower first entry bar its another reason why I think they stand a chance of working way into being included and even if they don't get include the install process should not be too horrible..
- Likes 1
Comment
-
Well, I did.
Anyone using Arch or a derivative can now easily-ish install dxvk:
The "difficult" part is getting mingw-w64-gcc working, which is a dependency. Follow the instructions here:
- Likes 2
Comment
-
I tried to set up some hourly builds (when there have been commits) that build in a opensuse tumbleweed docker container (because there's mingw from open build service for it).
stripped release builds + info on how to set it up: https://haagch.frickel.club/files/dxvk/
Kinda untested.
The dll registering script uses the path from --prefix hardcoded so I used /dxvk/32/bin/... and /dxvk/64/bin/... for that which everyone can create. You can probably just edit the script to change the path if you want to register them anywhere else, and they want to set it to $PWD or so in the future upstream.
If you once registered the dlls, just replacing them with new ones should work.
I think the dll redirecting stuff they use only works in wine staging right now.
Comment
-
Originally posted by haagch View PostI tried to set up some hourly builds (when there have been commits) that build in a opensuse tumbleweed docker container (because there's mingw from open build service for it).
stripped release builds + info on how to set it up: https://haagch.frickel.club/files/dxvk/
Kinda untested.
The dll registering script uses the path from --prefix hardcoded so I used /dxvk/32/bin/... and /dxvk/64/bin/... for that which everyone can create. You can probably just edit the script to change the path if you want to register them anywhere else, and they want to set it to $PWD or so in the future upstream.
If you once registered the dlls, just replacing them with new ones should work.
I think the dll redirecting stuff they use only works in wine staging right now.
Unfortunately DllRedirects is still in staging because there is a known bug. In mainline the recommend would be replace the fake dll with mingw build dll and set it native as it does not cause the case of the two different dlls loading at the same time.
Wine test based development forbids including all lot things that get stuck in staging due to bugs in this class where something works 99.9 percent of the time but 0.1 or less causes applications to fail and causes test suite to fail. But the rules are the rules.
Comment
Comment