How did CrossOver implement DX12 for CrossOver v23? Is it included in the Wineskin CX engines?

[sofakng]

If I understand correctly, and as listed on the main WineskinServer page, there are three possible libraries for DirectX support:

D3DMetal, WineD3D, and DXVK

However, it seems like CrossOver v23 included some DX12 support of their own. Is it possible to try these in Wineskin? Is this already included and considered the base WineD3D?

EDIT: It looks like CrossOver 23.7 (beta) also mentioned improving MoltenVK (used by DXVK??) so is that something else that might be different between Wineskin and CrossOver?

[Gcenx]

If I understand correctly, and as listed on the main WineskinServer page, there are three possible libraries for DirectX support:

D3DMetal, WineD3D, and DXVK

And VKD3D for DirectX12 as of CX23.x

However, it seems like CrossOver v23 included some DX12 support of their own. Is it possible to try these in Wineskin?

While it’s included it won’t really work properly without using a source build of MoltenVK from CodeWeavers, I’ve only been shipping stock MoltenVK recently.

It looks like CrossOver 23.7 (beta) also mentioned improving MoltenVK (used by DXVK??) so is that something else that might be different between Wineskin and CrossOver?

Yes CrossOver-23.7.0 beta slightly modified there custom MoltenVK but that won’t affect DXVK in anyway only WineD3D Vulkan & VKD3D.

Something to keep in mind is WineD3D Vulkan is usually slower than DXVK in most cases, VKD3D supports Diablo2: Resurrected & Diablo 4 currently.

[Gcenx]

Could we just copy libMoltenVK.dylib and VK3D DLLs from CrossOver? (I'm not sure if this is against the license though)

While you could that would lightly violate CrossOver license, they do provide sources for there custom version of MoltenVK however.

Also, when you say WineD3D Vulkan is this the same as the base WineD3D DLLs or is that a variation of it?

WineD3D has two backends, one using OpenGL and the other using Vulkan.

The above are already included.

I'd like to build a small app (similar to CXPatcher) that would allow Wineskin wrappers to switch between all different DirectX wrappers for testing, experimenting, etc. For example we could use that to build a spreadsheet of how games perform under each library or issues, etc.

This wouldn’t exactly be viable with how DXVK gets installed.

That’s also ignoring that D3DMetal replaces some file files, swapping them out would require wineboot -u to be ran to force upgrade the wrappers prefix.

I honestly don’t think it’s worth the effort currently.

[sofakng]

Thanks as always for all of the information.

Can you explain why replacing the files isn't viable for D3DMetal and DXVK?

If I understand correctly, DXVK only consists of three DLLs (dxgi.dll, d3d10core.dll, and d3d11.dll, and d3d9.dll). D3DMetal also uses the same DLLs (plus d3d12.dll and atidxx64.dll). However, D3DMetal has an additional dylib (libd3dshared.dylib) and a framework (D3DMetal.framework).

I would have thought that libd3dshared.dylib could always exist as well as D3DMetal.framework. They just won't be used depending on the files in the directories listed below.

The only files that would require changing are the 'built-in' Wine files:

Contents/SharedSupport/wine/lib/wine/i386-windows (32-bit Windows D3D DLLs)
Contents/SharedSupport/wine/lib/wine/x86_64-unix (dylib symlinks for D3DMetal; doesn't exist for others)
Contents/SharedSupport/wine/lib/wine/x86_64-windows (64-bit Windows D3D DLLs)

These would obviously need to have the correct set of files for what you are trying to use (ie. do not mix D3DMetal d3d*.dll/dxgi.dll with others)

Thanks again for taking the time to explain everything and helping me better understand how it works.

[Gcenx]

Can you explain why replacing the files isn't viable for D3DMetal and DXVK?

Because D3DMetal replaces files on wines side where DXVK files are installed into the wineprefix, DXVK requires the wine version of dxgi

If I understand correctly, DXVK only consists of three DLLs (dxgi.dll, d3d10core.dll, and d3d11.dll, and d3d9.dll). D3DMetal also uses the same DLLs (plus d3d12.dll and atidxx64.dll). However, D3DMetal has an additional dylib (libd3dshared.dylib) and a framework (D3DMetal.framework).

D3DMetal we only care about atidxx64, d3d11, d2d12 & dxgi files inside x86_64-unix & x86_64-windows, these replace wines own files.

DXVK we only use d3d10core & d3d11, we need to use wines dxgi not D3DMetal nor DXVK version, d3d10core & d3d11 need to be set to native,builtin and installed into the prefix to function.

I would have thought that libd3dshared.dylib could always exist as well as D3DMetal.framework. They just won't be used depending on the files in the directories listed below.

You could indeed leave those inside the Engine and probably even leave the symlinks inside x86_64-unix as wines own version of these files are PE not unix shims like what Apple provides.

[sofakng]

OK - Please help me understand a bit more...

There are two "sides" to every wrapper, right?

• SteamWine.app/Contents/SharedSupport/prefix
• SteamWine.app/Contents/SharedSupport/wine

The first is the prefix containing the drive_c (and configuration files, registry, etc)
The second is the "wine side" containing the actual WINE binary and a few library folders (i386-windows, x86_64-unix, x86_64-windows)

Do I understand that correctly so far?

What is the purpose of the library folders? Are these the "built-in" files provided by WINE?

There appear to be two Windows folders (32-bit and 64-bit) PE binaries and one unix. I'm guessing we can ignore i386-windows since that's probably for 32-bit only.

What is the interaction then between x86_64-windows and x86-unix?

For example, GPTK provides d3d10.dll and d3d10.so (which points to libd3dshared.dylib). I'm doing research and trying to understand so my guess is that the PE binary d3d10.dll is loaded by Windows and then WINE has a PE <-> UNIX layer which eventually loads libd3dshared.dylib.

Thanks again for helping me understand everything.

[Gcenx]

prefix = fake windows environment
wine = builtin

.so = unix file (used to load the unix side)
Video decoding is done by GStreamer on the macOS side.

Everything else is simply a replacement windows file