Created attachment 241865 [details] v1 (apply via "git am") Depends on ports 13d5524a0dec - Adjust LIBGL_DRIVERS_PATH to prefer -devel (ignored if not installed) - Respect libmap.conf(5) in 32-bit packages (e.g., mesa-devel, nvidia-driver < 410) Disclaimer: I don't use Wine, so only tested via glxgears, eglgears_x11, vkcube-xcb.
Thank you, Jan. I will admit I am not using WoW myself and am happy to trust and defer to you. Only and ask and a question: - Can you please describe the Why? beyond the What? (in the commit message)? - This Bugzilla entry reads "support graphics/mesa-devel" and the commit message has "Adjust LIBGL_DRIVERS_PATH to prefer -devel". To me it looks this goes beyond supporting and preferring to outright using -devel or the main ports? (Related to the ask, do you see this is a temporary measure? I.e., when and why would we switch back? We usually have not been depending on -devel ports.) Note: Damjan maintains wine-devel these days, so let me copy him, and please give him some time to chime in.
FreeBSD ports lack variables dependencies (aka Arch provides/requires, Debian alternatives, Gentoo slots). mesa-devel uses libmap.conf(5) to prioritize itself (over mesa-dri and mesa-libs) for all OpenGL and Vulkan applications. LIBGL_DRIVERS_PATH requires explicit support because wine* already override defaults in order to point to I386_ROOT. When LIBGL_DRIVERS_PATH isn't defined OpenGL uses the path embedded in libGLX_mesa.so and libEGL_mesa.so or (if mesa-devel is installed) libGLX_mesa-devel.so and libEGL_mesa-devel.so. Note, on NVIDIA GPUs libGLX_nvidia.so and libEGL_nvidia.so are used instead which don't support LIBGL_DRIVERS_PATH because there's only one driver, so no need for another dispatcher. $ pkg install mesa-devel glx-utils $ LIBGL_DEBUG=verbose glxgears [...] libGL: using driver i915 for 4 libGL: pci id for fd 4: 8086:1912, driver iris libGL: MESA-LOADER: dlopen(/usr/local/lib/dri-devel/iris_dri.so) [...] libGL: Using DRI3 for screen 0 Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. ^C (In reply to Gerald Pfeifer from comment #1) > - Can you please describe the Why? beyond the What? (in the commit > message)? Because only emulators/wine* ports implement I386_ROOT. Other ports already support mesa-devel. > - This Bugzilla entry reads "support graphics/mesa-devel" and the > commit message has "Adjust LIBGL_DRIVERS_PATH to prefer -devel". This mimics how mesa-devel works outside of I386_ROOT and has no impact if mesa-devel isn't installed. > To me it looks this goes beyond supporting and preferring to outright > using -devel or the main ports? Without variable dependencies replacing a package with many consumers is only possible via hacks like libmap.conf(5). LIBGL_DRIVERS_PATH alone isn't enough to use mesa-devel as mixing Mesa libs from different versions can lead to crashes, primarily because libglapi.so has unstable ABI. nvidia-driver >= 410 uses libglvnd but Mesa poorly supports multiple versions installed at the same time. For example, Xorg hardcodes "mesa" as GLX_EXT_libglvnd fallback instead of using __GLX_VENDOR_LIBRARY_NAME (besides, Xorg runs as root via setuid bit, so won't inherit environ(7) from a regular user), Vulkan ICD doesn't support libglvnd thus creates duplicate devices with the same name. > (Related to the ask, do you see this is a temporary measure? I.e., when > and why would we switch back? We usually have not been depending on > -devel ports.) It's not temporary. pkg has provides/requires (currently used to track shared libraries) but ports/ support is still missing. mesa-devel can be built standalone via DEFAULT_VERSIONS+=gl=mesa-devel but this is incompatible with binary packages (unless one creates dummy mesa-dri and mesa-libs) thus not recommended for regular users.
Created attachment 241907 [details] v1 (apply via "git am") Apply to wine-proton where wine-wow64.sh originated (bug 255381).
(In reply to Jan Beich from comment #3) Looks reasonable to me, although I'm not going to test either. (In reply to Gerald Pfeifer from comment #1) > (Related to the ask, do you see this is a temporary measure? I.e., when > and why would we switch back? We usually have not been depending on > -devel ports.) I expect these port hacks to persist until upstream fully implements their new WoW64 architecture. There is no time frame for that, especially since none of us are capable of debugging this stuff on FreeBSD, so it might take a while even after it works properly on Linux.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=83cf9277fc61e6e9c449df858a6d7b41e39bb08c commit 83cf9277fc61e6e9c449df858a6d7b41e39bb08c Author: Jan Beich <jbeich@FreeBSD.org> AuthorDate: 2023-04-29 21:08:28 +0000 Commit: Jan Beich <jbeich@FreeBSD.org> CommitDate: 2023-06-29 00:57:50 +0000 emulators/wine: support graphics/mesa-devel for WoW64 WoW64 currently uses i386 packages on amd64 under special PREFIX, so - Include mesa-devel paths to LIBGL_DRIVERS_PATH override - Respect libmap.conf(5) in 32-bit packages To use simply install mesa-devel as regular and WoW64 package e.g., $ pkg install mesa-devel $ /usr/local/share/wine/pkg32.sh install mesa-devel In case of issues simply remove mesa-devel e.g., $ pkg delete mesa-devel $ /usr/local/share/wine/pkg32.sh delete mesa-devel PR: 271140 Reviewed by: Alex S Approved by: maintainer timeout (2 months) emulators/wine-devel/Makefile | 2 +- emulators/wine-devel/files/wine-wow64.sh | 4 +++- emulators/wine-proton/Makefile | 2 +- emulators/wine-proton/files/wine-wow64.sh | 4 +++- emulators/wine/Makefile | 2 +- emulators/wine/files/wine-wow64.sh | 4 +++- 6 files changed, 12 insertions(+), 6 deletions(-)
Hello, i would like to report that this works as expected and thank you for the patch! Tested OpenGL (WINED3D) and Vulkan (DXVK) Game: LEGOIndyDEMO.exe info: DXVK: v1.10.3 info: Built-in extension providers: info: Win32 WSI info: OpenVR info: OpenXR info: OpenVR: could not open registry key, status 2 info: OpenVR: Failed to locate module info: Enabled instance extensions: info: VK_KHR_get_surface_capabilities2 info: VK_KHR_surface info: VK_KHR_win32_surface info: D3D9: VK_FORMAT_D24_UNORM_S8_UINT -> VK_FORMAT_D32_SFLOAT_S8_UINT info: AMD Radeon RX 6700 XT (RADV NAVI22): info: Driver: 23.1.99 info: Vulkan: 1.3.255
(In reply to commit-hook from comment #5) > Approved by: maintainer timeout (2 months) Apologies, I literally missed the updates after my question. That said, you are more then welcome to consider improvements/fixes to the (new) wine7 and wine ports pre-approved, Jan. Also happy to hand them over. :-)