DXMT targets 3Shain/wine (Wine 8.16). I ported the DXMT-enabling Wine patches to mainline Wine 11.9 and got a Unity 2022 D3D11 game rendering at FL11.1 on Apple M2, but it needed three changes beyond the 8.16 patches. Filing this to document what differs on Wine 11.x and offer a reference implementation.
Symptoms on stock Wine 11.9
d3d11_swapchain.cpp: Failed to create metal view, it seems like your Wine has no exported symbols needed by DXMT.
Root causes & fixes
-
macdrv_functions not reachable via dlsym(RTLD_DEFAULT). Wine 11.x loads driver unixlibs with dlopen(..., RTLD_NOW) (i.e. RTLD_LOCAL on macOS) in ntdll/unix/loader.c load_unixlib_by_name. Even with macdrv_functions exported from winemac.so, winemetal_unix.c's dlsym(RTLD_DEFAULT, "macdrv_functions") can't see it. Fix: load with RTLD_NOW | RTLD_GLOBAL (per-handle dlsym of __wine_unix_call_funcs is unaffected).
-
macdrv_win_data layout changed. DXMT's winemetal_unix.c expects { hwnd; cocoa_window; cocoa_view; client_cocoa_view; } (8.16). Wine 11.x dropped cocoa_view; the struct is now { hwnd; cocoa_window; client_view; ... }, so reading win_data->client_cocoa_view is at the wrong offset.
-
No persistent window view. Wine 11.x only attaches a client view via a client surface (macdrv_client_surface_update), so client_view is NULL when DXMT calls get_win_data during swapchain creation — there's no view to create the Metal view on.
Reference implementation
I worked around (2)+(3) by exporting a macdrv_functions table whose get_win_data shim returns a DXMT-layout struct and creates+attaches a view on demand if none exists, plus the RTLD_GLOBAL change:
cyyever/wine@c5375ee66cb
A cleaner long-term fix might be for the macdrv_functions table to expose create_metal_view_from_hwnd(hwnd, device) directly, so DXMT doesn't depend on the internal macdrv_win_data layout at all. Happy to help adapt this for an official Wine 11.x base if useful.
DXMT targets
3Shain/wine(Wine 8.16). I ported the DXMT-enabling Wine patches to mainline Wine 11.9 and got a Unity 2022 D3D11 game rendering at FL11.1 on Apple M2, but it needed three changes beyond the 8.16 patches. Filing this to document what differs on Wine 11.x and offer a reference implementation.Symptoms on stock Wine 11.9
d3d11_swapchain.cpp:Failed to create metal view, it seems like your Wine has no exported symbols needed by DXMT.Root causes & fixes
macdrv_functionsnot reachable viadlsym(RTLD_DEFAULT). Wine 11.x loads driver unixlibs withdlopen(..., RTLD_NOW)(i.e.RTLD_LOCALon macOS) inntdll/unix/loader.cload_unixlib_by_name. Even withmacdrv_functionsexported fromwinemac.so,winemetal_unix.c'sdlsym(RTLD_DEFAULT, "macdrv_functions")can't see it. Fix: load withRTLD_NOW | RTLD_GLOBAL(per-handle dlsym of__wine_unix_call_funcsis unaffected).macdrv_win_datalayout changed. DXMT'swinemetal_unix.cexpects{ hwnd; cocoa_window; cocoa_view; client_cocoa_view; }(8.16). Wine 11.x droppedcocoa_view; the struct is now{ hwnd; cocoa_window; client_view; ... }, so readingwin_data->client_cocoa_viewis at the wrong offset.No persistent window view. Wine 11.x only attaches a client view via a client surface (
macdrv_client_surface_update), soclient_viewis NULL when DXMT callsget_win_dataduring swapchain creation — there's no view to create the Metal view on.Reference implementation
I worked around (2)+(3) by exporting a
macdrv_functionstable whoseget_win_datashim returns a DXMT-layout struct and creates+attaches a view on demand if none exists, plus theRTLD_GLOBALchange:cyyever/wine@c5375ee66cb
A cleaner long-term fix might be for the
macdrv_functionstable to exposecreate_metal_view_from_hwnd(hwnd, device)directly, so DXMT doesn't depend on the internalmacdrv_win_datalayout at all. Happy to help adapt this for an official Wine 11.x base if useful.