DXVK patchset has improved alot and is being used by many Linux gamers to play DX11 games due to its great compatibility and reduced overhead: https://github.com/doitsujin/dxvk So can you please make a package (wine-dxvk) similar to wine-d3d9 which contains Gallium Nine patchset? Or better yet, make wine-vulkan package which supports both patchsets: dxvk (For DX11 emulation) and vkd3d (DX12 emulation).
The tricky thing with dxvk is, first, it isn't part of the wine source tree at all. Also, it requires a cross-compiler. Or at least it did when I figured out how to make it work. Maybe now there is a way to do it with winegcc which could be integrated. To make it work what I "had" to do was "crossdev -t cross-{x86_64,i686}-w64-mingw32", fix all the inevitable crashes and problems, and then inject EXTRA_ECONF="--enable-threads=posix" into /etc/portage/env/cross-{x86_64,i686}-w64-mingw32, re-emerge everything in $(qlist -ISC cross-), and then check out dxvk from git, build that according to its instructions (using the cross-compilers generated by crossdev), and then use the generated "dxvk installations" to modify WINEPREFIXes piecemeal. Needless to say these steps are: o Far outside the scope of anything portage does with wine right now o Not something even remotely user-friendly In theory, however, since dxvk simply modifies the wine registry a bit and overrides a couple of dlls, there is no reason it /couldn't/ be made to work. Just saying to build it from source is not going to be a trivial endeavour, and then you end up with a very nonstandard "dxvk-only" wine which is not how upstream dxvk works. Maybe the best thing to do for a first step would be to make an app-emulation/dxvk-bin package which provides the dlls and setup_dxvk.sh?
A couple of clarifications (In reply to Greg Turner from comment #1) > The tricky thing with dxvk is, first, it isn't part of the wine source tree > at all. That is to say, dxvk is not a wine patchset at all. Rather, it's an independent source tree which enables one to patch wine installations (prefixes) by replacing upstream wine binaries with its own versions. So, app-emulation/wine-* is not actually modified at all by dxvk. > ... inject > > EXTRA_ECONF="--enable-threads=posix" > > into /etc/portage/env/cross-{x86_64,i686}-w64-mingw32 thinko... this should read /etc/portage/env/cross-{x86_64,i686}-w64-mingw32/gcc.conf
Yeah, I don't see this ever being a source package due to the cross compiler requirement. I'll consider adding it as a binary package with the scripts. Sarnex
After discussing this with some of my colleagues in #gentoo-wine, I have decided to not create the binary package. Firstly, winetricks has a dxvk verb that will download the dxvk binaries, install them in your prefix, and create the required DLL overrides. https://github.com/Winetricks/winetricks/commit/97a3c5ac02cea11193bd6371c200f8c1e47d2fa3 Secondly, a great overlay exists which has ebuilds for those who want to build dxvk from source: https://github.com/pchome/dxvk-gentoo-overlay As I mentioned before, source builds aren't really maintainable in the main tree. I recommend users picking one of these options to get DXVK running on their system. Thanks, Sarnex
(In reply to Nick Sarnie from comment #4) > After discussing this with some of my colleagues in #gentoo-wine, I have > decided to not create the binary package. > > Firstly, winetricks has a dxvk verb that will download the dxvk binaries, > install them in your prefix, and create the required DLL overrides. > > https://github.com/Winetricks/winetricks/commit/ > 97a3c5ac02cea11193bd6371c200f8c1e47d2fa3 > > Secondly, a great overlay exists which has ebuilds for those who want to > build dxvk from source: > https://github.com/pchome/dxvk-gentoo-overlay Wow, nifty! It does, indeed look like this overlay manages to get winegcc to do the compilling; I'll have to give it a try sometime. > As I mentioned before, source builds aren't really maintainable in the main > tree. > > I recommend users picking one of these options to get DXVK running on their > system. It's unfortunate , but I completely understand given the current state of affairs -- someone would need to do a lot of head-scratching & hard work to keep it working, or it would suck, or both :) dxvk's build infrastructure is in flux; indeed my comment below about the setup-dxvk.sh script is no longer applicable to current git (which now uses a winetricks script). I have the impression that the developers are aware that the status quo is not super convenient for everybody and are working on it. Hopefully things will get better from the perspective of the hypothetical/actual dxvk ebuild author... With some luck, these complicating factors might be solved upstream in the not-to-distant future.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b458663e8d42a6932d1be1664324fcd707e28b04 commit b458663e8d42a6932d1be1664324fcd707e28b04 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2022-05-07 04:39:10 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2022-05-13 02:29:29 +0000 app-emulation/dxvk: new package, add 1.10.1 + live Many want to build this, but crossdev requirement made it unsuitable for ::gentoo. Now, mingw64-toolchain is there to remedy this and so let's add it. crossdev can still be used if USE=crossdev-mingw Note that unlike most overlays, this intentionally does not modify config.cpp and then installs dxvk.conf as a documentation example. Use the intended ${PWD}/dxvk.conf or DXVK_CONFIG_FILE env var. Paths are also different (using lib64 is not necessary and requires workarounds), so may need to update WINEPREFIX symlinks. Closes: https://bugs.gentoo.org/664310 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> app-emulation/dxvk/Manifest | 1 + app-emulation/dxvk/dxvk-1.10.1.ebuild | 120 ++++++++++++++++++++++++++++++++++ app-emulation/dxvk/dxvk-9999.ebuild | 120 ++++++++++++++++++++++++++++++++++ app-emulation/dxvk/metadata.xml | 21 ++++++ 4 files changed, 262 insertions(+)
