mesa-25.1.8

[zeckma]

New bugfix release.

Let's wait until the final bugfix release in the 25.1 series.

[zeckma]

Now 25.1.5.

[zeckma]

Since I'm waiting on the final bugfix for Mesa of the 25.1 series, I want to go over my general plan of how to handle Mesa updates in BLFS. New minors/majors typically introduce a good amount of bugs, and often the bugfix that comes after doesn't fix all of them. The last bugfix version of a given major/minor should be more stable, but in some cases, bugfixes from previous majors/minors still persist.

Thus, my plan is after the last bugfix release drops in the 25.1 series, that we then wait for the last bugfix release in the next minor/major, like 25.2 or 26.1.

So the update scheme that can be expected will look like 25.1.3 -> 25.1.8 -> 25.2.8/26.1.8. This depends on what is actually the last bugfix update. It can range from 6 to 9 usually.

When I will update to the final bugfix release of this 25.1 series, I will remove the note on the Mesa page that recommends the user to use the latest release of the current minor series. In short, moving onto the next minor/major will not be recommended. This should keep the amount of updates very low.

The only exceptions should be when there is a security fix, and we can then decide whether to update to the next major/minor or make a patch.

[Bruce Dubbs]

That seems like a reasonable approach to me. We do that for several other packages, notably systemd. It cuts down on the churn and should not affect users.

[Xi Ruoyao]

I'm really not a fan of this policy. The development book is for development, including detecting a bug.

What would happen if we detect a bug after the final point release and the upstream has ceased the support of this release branch? Are we capable of triage and fixing it on our own??

[Xi Ruoyao]

Also for systemd we update to .0 rather early, not waiting for .9 or .10.

[zeckma]

Replying to Xi Ruoyao:

I'm really not a fan of this policy. The development book is for development, including detecting a bug.

I think two other solid options would to either:

1. Update to every bugfix release as we have always done up to this point, or...
2. <major>.<minor>.<first_bugfix> -> <major>.<minor>.<last_bugfix> -> <major>.<next_minor>.<first_bugfix> (like 25.1.1 -> 25.1.7 -> 25.2.1 -> 25.2.7)

What do you think, Xi? I wanna go forward with a plan most of us can agree on. I think option 1 wouldn't be ideal for a number of us, but option 2 sounds fine to me.

An important note too: many users use the development books, especially when following from MLFS which has no stable unless you render it yourself from a known stable git commit. However, they often don't want to run into many issues, which is why BLFS dev has to be solid to fill this use-case. I think this is a really good reason as to why we update to only official Vulkan SDK releases instead of what feels to be weekly or bi-weekly releases. As a user, I'd personally would want new features or speed improvements (like with Nouveau Vulkan) but without as many bugs. As a developer, it would help to know what bugs are present. I want to go with the users first approach, so I'm personally down with option 2, but would prefer my original plan.

[Bruce Dubbs]

Replying to zeckma:

Replying to Xi Ruoyao:

I'm really not a fan of this policy. The development book is for development, including detecting a bug.

I think two other solid options would to either:

1. Update to every bugfix release as we have always done up to this point, or...
2. <major>.<minor>.<first_bugfix> -> <major>.<minor>.<last_bugfix> -> <major>.<next_minor>.<first_bugfix> (like 25.1.1 -> 25.1.7 -> 25.2.1 -> 25.2.7)

What do you think, Xi? I wanna go forward with a plan most of us can agree on. I think option 1 wouldn't be ideal for a number of us, but option 2 sounds fine to me.

We need to take individual packages into account. In general we *do* want to update every bugfix, but we treat some packages differently. We only update the kernel minor version when we get a .1 release, otherwise twice a month. We only update kf6/plasma approximately every three months.

Some packages put out far too many changes an call them 'stable' when they are not. sentry_sdk is one example. vim has stopped putting out stable releases and basically every commit is a release.

llvm and mesa are also examples of lots of churn in the release process. It's really the editor who is generally doing those packages that is most familiar with what is going on and should make the decision to upgrade according to specific circumstances.

[zeckma]

Replying to Bruce Dubbs:

llvm and mesa are also examples of lots of churn in the release process. It's really the editor who is generally doing those packages that is most familiar with what is going on and should make the decision to upgrade according to specific circumstances.

The main reason why I went over my original plan was personal experience of using NVK, especially when Zink became the default Gallium3D driver for NVK. It seems to have introduced problems with each major/minor recently, like flashing and crashes in Firefox (I have reported the recent issues, but getting info seems to be have been really difficult for the recent ones). I don't really want users to experience those bugs, but rather them have a more stable experience, to not have to downgrade after getting burned. Since users use the development version in many cases, I want to ensure they don't run into those troublesome areas. Updating to every last bugfix will ensure the users have a more solid experience. When I update the version of a package in the book but keep my system at a lower version to have a less buggy experience, I think that's a problem.

I have taken most of the Mesa tickets recently, and will most likely take this one when it's ready. But I don't want to do something that we're not all on the same page about, especially when others have taken these tickets before me.

[Xi Ruoyao]

Maybe an alternative of 2: you try x.y.1 first and upgrade to it if you find no issue, otherwise you create a bug report to the upstream and note it in our ticket, and wait for x.y.2 an try ... until you get a stable state.

Regarding Zink I still don't think it's stable enough. When I try it out on my new laptop (using Core Ultra 5 125H integrated GPU) it makes some stupid black rectangles on the display. Maybe we should just invert the default value with Nouveau for now?

[zeckma]

That seems like a pretty reasonable approach to me. Still ensures a mostly stable experience while cutting down the churn. Also I agree with the Zink point. May be tricky setting default Gallium3D to nouveau (profile script, system-wide bashrc, or user profile?) Perhaps we can just recommend all the ways it can be done or go with a profile script.

[zeckma]

Now 25.1.6.

[zeckma]

Now 25.1.7. Likely the final release of 25.1 will be 25.1.8 as 25.2 now has rc3.

[zeckma]

If we don't see 25.2.1 before the package freeze, I will go with the latest bugfix release in 25.1, and the next release cycle will get 25.2.

[zeckma]

Now 25.1.8, final release of 25.1.

[zeckma]

Bug fixes from 25.1.3 to 25.1.8:

• vkGetPhysicalDeviceImageFormatProperties2 not correctly implemented for VK_FORMAT_G8_B8R8_2PLANE_420_UNORM + VK_IMAGE_CREATE_EXTENDED_USAGE_BIT
• anv, bmg: Striped pattern on ground in Heroes of Valor
• rusticl: Assertion failed for ACO and stuck for LLVM (radeonsi)
• New Mesa drivers failing to launch some flatpak apps
• [ANV][LNL/BMG] - The Last of Us™ Part II Remastered (2531310) - Multicolored dots present on some objects
• Oddworld: Strangers Wrath bad shading on NPC chickens
• RADV: Unimplemented instrinsic instr when creating a pipeline with a task shader
• FTBFS LLVM21 CLC error: no matching function for call to clang::TextDiagnosticPrinter
• v3d crashes on Raspberry Pi 5 if no monitor connected
• [ANV][LNL] - Sid Meier's Civilization VII (1295660) - Linux version hangs when starting the "Graphics Benchmark".
• Steam game recording on Intel ANV resulting in green corrupted image due to bug with VK_FORMAT_G8_B8R8_2PLANE_420_UNORM rendering
• Confidential issue #13432
• dzn: dzn_meta_init may return VK_SUCCESS when failing, leading to application crashes
• brw_nir_lower_cmat produces invalid NIR for OpVariable initializers
• src/asahi/lib/meson.build:65:52: ERROR: Unknown variable "inc_virtio_vdrm".
• hasvk_tests: ../src/vulkan/runtime/vk_log.c:40: vk_object_to_device: Assertion obj->device failed.
• radv: android: Why VkNativeBufferANDROID::handle::numFds must be 1 in function radv_image_from_gralloc
• Regression: Mesa 25.1.1 causes ground texture flickering in DOTA 2
• GPU process crash via WebGPU shader - wild-deref in Mesa try_opt_exclusive_scan_to_inclusive
• mesa:freedreno / cffdump-shadow failure
• v3dv: regression in vkAllocateMemory importing gbm bo
• Vulkan WSI (and zink) use threads on X11 even when the X connection isn't thread-safe
• sddm-greeter-qt segfault when using nvk+zink
• [regression][bisected] [FirePro W4100]: crashing/rebooting
• Descriptor set layout with binding flags fails due to indices not matching bindings
• piglit bindless texture tests crash
• [radeonsi] Artifacts in Team Fortress 2 (bisected)
• eglgears_wayland segfault on zink+nvk with PRIME
• vn_renderer_virtgpu.c:13:10: fatal error: 'xf86drm.h' file not found
• brw: mad instruction printing broken on Gfx11
• radv: RGB9E5 rendering does not ignore alpha write mask
• Confidential issue #13431
• High GPU usage when using Zink for eglgears_x11 (on X11)
• Segfault in X11 image acquire code with timeout=0
• Crash from iris_set_sampler_views in chromium/chrome with accelerated video decoding
• rusticl: aco: LLVM outperforms ACO in clpeak for short benchmarks on hawaii
• rusticl: aco: Performance regression in clpeak for char benchmarks on hawaii
• Race condition with timeline semaphores
• nir_algebraic silently ignores operand conditions in some cases
• lavapipe: valgrind triggers errors with CTS unit tests when creating a vulkan device
• radv: more glcts fails KHR-GL46.shading_language_420pack.initializer_list_initializer*
• radv: regression in KHR-GL46.gpu_shader5_gl.float_encoding
• radeonsi: Broken VAAPI video color conversion
• Build dependency on intel_wa.h missing in Intel vulkan driver
• vn_ring: use-after-release crash after vn_ring_destroy on Virtio-Vulkan
• venus: vkmark --winsys headless segfault (regression)
• Vulkan headless WSI crashes when initializing swapchain on Asahi Linux running Apple M1 Max
• [RADV] Graphical glitches in Ghost of Tsushima on Polaris
• Segfault when activating DPMS on i915 hardware
• radv: regression: commit a7291074c800 break lighting in Like a Dragon: Infinite Wealth

[zeckma]

Fixed at 4cfad82d29e8098a6ea7e217c2041fd3867a4817.