Page MenuHomeFreeBSD

graphics/mesa: Update to 25.0.0
Needs ReviewPublic

Authored by manu on Feb 24 2025, 1:13 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Oct 15, 10:12 PM
Unknown Object (File)
Sun, Oct 12, 12:52 AM
Unknown Object (File)
Thu, Oct 9, 11:27 AM
Unknown Object (File)
Mon, Oct 6, 5:15 AM
Unknown Object (File)
Thu, Oct 2, 12:52 PM
Unknown Object (File)
Sat, Sep 27, 2:16 AM
Unknown Object (File)
Sep 20 2025, 5:33 AM
Unknown Object (File)
Sep 17 2025, 8:18 AM

Details

Reviewers
None
Group Reviewers
x11
Summary

Sponsored by: Beckhoff Automation GMbH & Co. KG

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 62615
Build 59499: arc lint + arc unit

Event Timeline

manu requested review of this revision.Feb 24 2025, 1:13 PM
manu created this revision.
ziaee added inline comments.
graphics/mesa-dri/Makefile
8

When trying to build mesa-dri with this patch, it didn't build until I put the py-mako line here, based on what I read on the link below. I don't understand how this interacts with the similar line in Makefile.common.

Should py-ply be moved to anv_BUILD_DEPENDS? It's allegedly only for intel vulkan ray tracing according to: https://docs.mesa3d.org/meson.html#dependencies , and it built fine like that with the config below.

Curiously, upon reboot it scrambled all my xinput properties, e.g. Tap to Click has been property 371 for the last 6 months I've had this laptop, but now it's property 369. Other than that everything seems fine, but I'd like to know more about how to test this type of thing.

Tested with CURRENT from this morning with i915 with drm-66 and this buildconfig:

# make showconfig
===> The following configuration options are available for mesa-dri-25.0.0:
     ZSTD=on: Use ZSTD for shader cache
====> Unified OpenGL drivers
     crocus=off: Intel GPU Gen4 (Broadwater) to Gen7 (Haswell)
     i915=off: Intel GPU Gen3 (Grantsdale to Pineview)
     iris=on: Intel GPU Gen8 (Broadwell) and newer
     r300=off: AMD/ATI R300, R400 and R500
     r600=off: AMD/ATI R600, R700, Evergreen, Northern Islands
     radeonsi=off: AMD/ATI Southern Islands and newer
     svga=off: VMWare Virtual GPU
     swrast=off: Software Rasterizer
     zink=on: OpenGL on top of Khronos’ Vulkan API
====> Options available for the group PLATFORM
     X11=on: Enable X11 support for GBM/EGL
     WAYLAND=on: Enable Wayland support for GBM/EGL and Vulkan
====> Vulkan drivers
     anv=on: Intel GPU Gen9 and newer Vulkan support
     radv=off: AMD/ATI Southern Islands and newer Vulkan support
     swrast_vk=on: Software Rasterizer Vulkan support

full dmesg at https://people.freebsd.org/~ziaee/tmp/dmesg.20250224.mesa25

I don't want to put any pressure on it, but is there a reason why this is just sitting there?

The problems with the current mesa are not getting any less:

  • MPV triggering an unrecoverable GPU hang in my case with AMD Radeon RX 6700 XT. (Solved in mesa-devel)
  • VKD3D 2.14+ needs an newer Mesa as well otherwise unrecoverable GPU hang (Solved in mesa-devel)
  • DXVK has now bumped to the recommended Mesa version to 25. (Solved in mesa-devel [obviously])

Thank you.

monwarez_mailoo.org added inline comments.
graphics/mesa-dri/pkg-plist
46

This should be in mesa-libs instead, see my other comment.

graphics/mesa-libs/pkg-plist
16

It seems that libgallium should be in mesa-libs rather than mesa-dri.
When trying to build a dependencies of mesa-libs like sdl20, I get a complaint that it cannot install mesa-libs due to a missing shared library: libgallium

graphics/mesa-dri/pkg-plist
46

My bad, if it is not here it will blow up later

graphics/mesa-libs/pkg-plist
16

Yeah putting it here will make blow up the rest, I think the issue is that lib/gbm/dri_gbm.so depends on lib/libgallium-25.0.0.so

When I upgraded to 25.1.7 I noticed that I had to build all the drivers for both mesa-libs and mesa-dri since they now are all in one single libs: libdril_dri.so, and the others dri libs are a symlink to it.
The same occur for the gallium va drivers, so I guess the separation of all this repos is no longer a possibility.
Looking at mesa-devel, it is done in a single ports and works fine. I don't think that we could keep the multiple port architecture past 25.1.7.

I am now at 25.2.3 and I adapted the port to always build all the drivers on the mesa-gallium-va, mesa-dri and mesa-libs which is not really a great alternative since we are basically building the same things multiple times.