Initial winelib support (for hangover) #2138
Conversation
cwabbott0
changed the title
does this mean this is going to be running on non-x86 hardware? I don't think DXVK would even compile on that right now, and even when sorting that out I'm almost certain that we'll have to fix a few hundred memory visibility bugs and similar things first, because there has been no way to test this so far. Anyway, not particularly thrilled about having to add this maintenance burden back, but I guess we don't have much of a choice. |
|
Wouldn't it make more sense to just get MinGW working? You're going to need that going forward anyway so it makes more sense than bringing that maintenance burden here imo. |
I would absolutely love to have a working MinGW toolchain, after doing this I now know exactly how much the current setup sucks, but I just have no idea how one would go about achieving that and I don't think that's something I could reasonably take on myself. Also there are apparently thorny ABI issues (Microsoft reserved a register for the TEB that linux uses freely iiuc) that need to be solved somehow. |
Yes, the plan is to get it to replace wined3d with dxvk in hangover. The stack would use hangover for DLL thunking, with DXVK + turnip for D3D emulation, and eventually FEX instead of qemu for x86 emulation. On the turnip side we've implemented pretty much everything DXVK could want. I have a hacky setup with an older version of DXVK where it actually works for basic things, at least I got to the point of being able to replay a trace of a real game with a Windows version of apitrace running on top of this stack (except still with qemu). This is my attempt to start to clean it up and make it a coherent patch series that doesn't perturb the normal case. It's definitely still very experimental ATM, but at least it's a start. |
|
Pulled in some of the commits that don't add any winelib-specific stuff since they are useful, but I guess the question is whether want winelib support upstream or whether the build system changes could be maintained in an external fork. Changes that make it less painful are always welcome, but we're not likely to ever really test this in the first place. If a fork is an option, I'd also pull in 1053d5c without the |
We can't use the included static libraries obviously, and wine only ships the def file and implib for d3dcompiler.
Many places were changed to pass a wchar_t * argument when opening files to fix issues with non-ASCII filenames, but this won't work with winelib and causes build errors. Add a function to paper over this annoying difference and use it everywhere.
Winelib uses wine's d3d11 headers which have this enum but don't define __MINGW_VERSION_MAJOR.
winegcc doesn't support this.
Meson doesn't yet understand the whole executable wrapper thing, so just produce the raw .dll.so which is all we need anyway.
All of these are useless, because the set of symbols to export is determined by the def file and the set of symbols to import is determined by whatever undefined symbols are left after linking the object files together. Silence various warnings about these being ignored.
cwabbott0
force-pushed
the
winelib-support
branch
from
9e0bcae to
8c4c686
Compare
I needed to do this to use hangover's out-of-tree wrc since it needs --nls-dir passed to it.
|
I wish someone can help me to port dxvk to aarch64 native dll (or winelib). Because there is indeed a native aarch64 Windows game - World of Warcraft: Shadowlands. (https://us.forums.blizzard.com/en/wow/t/windows-10-arm64-support-now-available/961628) And I have a PC with an 4-core arm64 CPU and a regular PCI-e x16 slot, so I can install some Vulkan compatible NVIDIA or AMD graphics cards. The AMD Radeon HD 8570 graphics card it is now installed seems to be Vulkan compatible.
So if there is an aarch64 native DXVK, I can test whether the game can be launched on my computer. It does not work in wined3d now (with wine 6.13 aarch64 build):
I know that we may have a lot of work elsewhere in or outside of DXVK, but adding aarch64 support to DXVK builds will be a good start. |
Maybe take a look at https://github.com/mstorsjo/llvm-mingw? Haven't tried DXVK with it but a lot of sizable projects (ffmpeg, qt, vlc, etc) builds just fine targeting aarch64. Also IIRC it is used in PE conversion of wine in aarch64 target. |
|
People are using ARM64EC for this now. #3900 |
|
Are there prons or cons in using ARM64EC compared to winelib? |
For bringing up DXVK on hangover, we want to compile it in the host for performance reasons, and that entails compiling it as a winelib since there is no usable aarch64 mingw toolchain. This MR adds back support for winelib. However using it requires using a winegcc built with some patches I just sent to wine-devel https://www.winehq.org/pipermail/wine-devel/2021-July/190100.html. If you also don't like applying patches from mailing lists, they're available at https://github.com/cwabbott0/wine/tree/winegcc-meson.
This just gets things building on x86 as a first step. Later I will fix compilation with aarch64, and we also need to somehow deal with AndreRH/hangover#28 (comment).