void-linux
mesa: update to 25.3.1 (megamerge)
Testing the changes
- I tested the changes in this PR: YES
Local build testing
- I built this PR locally for my native architecture, (x86_64-LIBC, i686-LIBC, x86_64-musl)
Disregarding the rest of the changes you made, listing the distfiles and tools one by one would make the template a pita to maintain.
I have a utility that analyzes source code and solves this problem. I'll still think about how to simplify it. I also need to fix the removed patches.
I have a utility that analyzes source code and solves this problem.
could i take a look at it?
could i take a look at it?
https://github.com/onlylunix/simple-utilities/blob/main/gen_crates.sh
You need Meson 1.7.0 or later! I can't figure out how to do this in one commit. :)
You need Meson 1.7.0 or later! I can't figure out how to do this in one commit. :)
#56014 Please convert to draft
just wanted to add about the meson thing - i think the PR creator isn't using github anymore? also the last comment mentions meson should be past that PR (1.8.4).
Thanks for doing the PR. Will this solve the problem with x32 games and Vulkan?: https://github.com/doitsujin/dxvk/issues/5219
I've been having a similar problem with Mesa 25.1.9 for a week... I saw your workaround but I don't have that library_arch variable in the .jsons in the first place.
0024:err:vulkan:wine_vk_instance_init_physical_devices Failed to enumerate physical devices, res=-3
Thanks for doing the PR. Will this solve the problem with x32 games and Vulkan?: doitsujin/dxvk#5219
Yes, this issue has been resolved.
I've been having a similar problem with Mesa 25.1.9 for a week... I saw your workaround but I don't have that library_arch variable in the .jsons in the first place. 0024:err:vulkan:wine_vk_instance_init_physical_devices Failed to enumerate physical devices, res=-3
Your problem is something else.
Sorry but why are some of these Rust crates being vendored anyway?
seconded. i know cmake has this type of thing disabled because it can be sneaky
ERROR: Subproject syn is buildable: NO
src/compiler/rust/meson.build:126:10: ERROR: Automatic wrap-based subproject downloading is disabled
A full log can be found at /builddir/mesa-25.2.5/build/meson-logs/meson-log.txt
fwiw, my version w/o rust stuff in separate files.
also think libxatracker needs to be removed or temporary faked for remove in remove-packages 'package'
also-also fwiw - meson 1.9.1 https://github.com/void-linux/void-packages/pull/57635
also think
libxatrackerneeds to be removed or temporary faked for remove inremove-packages'package'
@zlice Done. Also xf86-video-vmware depends on libxatracker. Increased the xf86-video-vmware revision for rebuilding
The vendoring appears to be done at least on Alpine Linux to enable NVK, idk enough about Mesa's features here to really be able to comment but fair enough I guess: https://git.alpinelinux.org/aports/commit/main?id=a67dc80ad7aa89c821961b84f3fa0940129bbfde
It is advisable to wait for the backport https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38017
Hi guys, I am just chiming in with a report, that this update seems to be mandatory for standalone inside out tracking VR devices like Quest family and SteamVR to work on Void Linux natively.
Directly connected HMDs like Valve Index or HTC Vive family don't need this, as they present to SteamVR as a special monitor and supposedly already work, so this is needed only for so called "wifi streaming".
Recently, Valve updated their SteamVR stack (at least beta version of it) to work in this "wifi" mode, on Linux, natively, and closed its "meta-issue" at https://github.com/ValveSoftware/SteamVR-for-Linux/issues/655 for that, so from their POV, and after two years of waiting, the major work is done.
So I tried to test it.
VR stack in my setup is intended to be used with eGPU.
I first tried this with NVIDIA eGPU ... and it somehow works, but it is highly unstable and buggy as hell. NVIDIA provides it's own "everything" (especially Vulkan ICDs, which SteamVR relies on completely) and doesn't seem to be using mesa at all, only vulkan-loader, so this exact issue doesn't pop up in that setup at all.
On NVIDIA sometimes the VR connection spins up, but then it explodes after some minutes in a VR game. But due to extremely esoteric nature of combination of Void + NVIDIA + Steam + SteamVR, the issues are completely undebuggable for any mere mortal.
Then I got my hands on AMDGPU card and after some tweaking of Xorg, boot Steam and "masking" of all NVIDIA Vulkan stuff (my system still has onboard NVIDIA dGPU and driver for that affects Vulkan, more specifically vulkan-loader, unless all NVIDIA vulkan ICDs and layer .json's are removed), all Proton games started to work flawlessly!
On amdgpu+mesa frame rates are super stable and dual mode games with both Desktop and VR modes do work in Desktop mode perfectly (both Proton or native). Unfortunately amdgpu stuff also relies heavily on mesa to provide Vulkan layer and other GL/Vulkan things.
When on amdgpu solely, SteamVR seems to boot fine as well, but as soon as one tries to connect to it from HMD, they are greeted with this message:
:(.
This means that until mesa is bumped to this PR, all VR devices in "inside out" family like Quest 1, 2, 3, Pico, etc still won't work on Void on NVIDIA-less systems (mostly AMDGPUs, but maybe also Intel Arcs).
I hope I am not the only one in the world who has this "esoteric" combination of Void, Steam and Quest 3, and after years of trying and failing, I believe this update, should it work, would be major milestone for VR on Void (Quest users outnumber Index users by 1:10).
@classabbyamp
can we enable this #57684 ?
Version 25.1.9 and this 25.2.x already include Rusticl. For example, for Intel, you can get the following output:
$ RUSTICL_ENABLE=iris clinfo | grep 'Platform Name\|Device Name\|Version' -A1
Platform Name rusticl
Platform Vendor Mesa/X.org
Platform Version OpenCL 3.0
Platform Profile FULL_PROFILE
--
Platform Extensions with Version cl_khr_icd 0x800000 (2.0.0)
cl_khr_byte_addressable_store 0x400000 (1.0.0)
--
Platform Numeric Version 0xc00000 (3.0.0)
Platform Extensions function suffix MESA
--
Platform Name rusticl
Number of devices 1
Device Name Mesa Intel(R) HD Graphics 630 (KBL GT2)
Device Vendor Intel
--
Device Version OpenCL 3.0
Device UUID 86801259-0400-0000-0002-000000000000
--
Device Numeric Version 0xc00000 (3.0.0)
Driver Version 25.2.7
Device OpenCL C Version OpenCL C 1.2
Device OpenCL C Numeric Version 0x402000 (1.2.0)
Device OpenCL C all versions OpenCL C 0xc00000 (3.0.0)
--
Device Extensions with Version cl_khr_byte_addressable_store 0x400000 (1.0.0)
cl_khr_create_command_queue 0x400000 (1.0.0)
--
Platform Name rusticl
Device Name Mesa Intel(R) HD Graphics 630 (KBL GT2)
clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU) No devices found in platform
--
Platform Name rusticl
Device Name Mesa Intel(R) HD Graphics 630 (KBL GT2)
clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR) No devices found in platform
--
Platform Name rusticl
Device Name Mesa Intel(R) HD Graphics 630 (KBL GT2)
--
ICD loader Version 2.3.2
ICD loader Profile OpenCL 3.0
v3d support is available in the mesa-v3d-dri metapackage (aarch64). I couldn't find any other information about Rusticl support for the VideoCore VII GPU at https://docs.mesa3d.org/rusticl.
Thanks for updating this, I've been running 25.2.6 from this PR for several days, no issues. I just built 25.2.7 and it's working nicely as well!
@KeepBotting so that means if I pull this branch and build this package from void-packages I could try on my setup?
Yes, apparently there is some potential issue with Intel until https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38017 is merged into 25.2 but I am on AMD and no issues here!
Fwiw, running mesa-25.2.7 (built locally for x86_64-glibc from minimal template) on an Intel HD Graphics 620 w/o issues (wayland, no gaming, video playback w/ vaapi)
Fwiw, running
mesa-25.2.7(built locally for x86_64-glibc from minimal template) on an Intel HD Graphics 620 w/o issues (wayland, no gaming, video playback w/ vaapi)
After the 25.2.7 release, commits with fixes quickly appeared. Should they be included in patches? https://gitlab.freedesktop.org/mesa/mesa/-/commits/staging%2F25.2?ref_type=heads
Since v25.2.7 isn't packaged yet, better wait for the next release instead
@dogknowsnx Version 25.3.0 has been released. Should I make it a separate PR?
@dogknowsnx Version 25.3.0 has been released. Should I make it a separate PR?
Just keep this PR up-to-date and only use official releases
@dogknowsnx
Fixed gen_template_crates to be more correct, since directory and patch_directory may not match in newer versions of Mesa (e.g. 25.3.0).
Well, my personal contribution to this PR is limited to testing mesa releases custom built for my hardware.
Eventually a Void member will have to decide whether to adopt your approach also with regard to future maintainability.
EDIT: Maybe explain/comment early in the template the need for issuing gen_template_crates