stable

mesa-24.3.3-2.fc41

FEDORA-2025-6fbd8f368a created by jexposit 2 months ago for Fedora 41

mesa v24.3.3

How to install

Updates may require up to 24 hours to propagate to mirrors. If the following command doesn't work, please retry later:

sudo dnf upgrade --refresh --advisory=FEDORA-2025-6fbd8f368a

This update has been submitted for testing by jexposit.

2 months ago

This update's test gating status has been changed to 'waiting'.

2 months ago

This update's test gating status has been changed to 'waiting'.

2 months ago

This update's test gating status has been changed to 'passed'.

2 months ago
User Icon markec provided feedback 2 months ago
BZ#2335454 mesa-24.3.3 is available
User Icon marok provided feedback 2 months ago
karma
User Icon markec provided feedback 2 months ago
karma
User Icon g6avk commented & provided feedback 2 months ago
karma

Works for me..

BZ#2335454 mesa-24.3.3 is available
User Icon agurenko provided feedback 2 months ago
karma

This update has been pushed to testing.

2 months ago

This update can be pushed to stable now if the maintainer wishes

2 months ago
User Icon imabug provided feedback 2 months ago
karma
BZ#2335454 mesa-24.3.3 is available
User Icon bojan commented & provided feedback 2 months ago
karma

Works.

User Icon micmor commented & provided feedback 2 months ago

Ok except egl-utils, bug report, here : https://bugzilla.redhat.com/show_bug.cgi?id=2337082

User Icon besser82 commented & provided feedback 2 months ago
karma

Works great! LGTM! =)

User Icon derekenz commented & provided feedback 2 months ago
karma

Works

karma
User Icon egeretto provided feedback 2 months ago
karma
BZ#2335454 mesa-24.3.3 is available
karma
BZ#2335454 mesa-24.3.3 is available
User Icon filiperosset commented & provided feedback 2 months ago
karma

no regressions noted

User Icon bitlord commented & provided feedback 2 months ago

For me it seems that there is a regression on my hybrid graphics setup, for some reason it picks up nvidia gpu (confirmed by glxinfo64 -B as well as nvidia-smi while in bios it was still set to hybrid graphics like before). And everything becomes really slow.

01:00.0 VGA compatible controller: NVIDIA Corporation GA106M [GeForce RTX 3060 Mobile / Max-Q] (rev a1)
35:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt [Radeon 680M] (rev c8)

Maybe there other updates as well with this combination that make it work like that, but if I only downgrade mesa to mesa-*:24.3.2-2.fc41.x86_64 everything starts working normally again.

User Icon bitlord commented & provided feedback 2 months ago

Addition to my previous comment.

it is also visible from the log that nvidia is being used

new mesa

gnome-shell[2253]: Device '/dev/dri/card0' prefers shadow buffer
gnome-shell[2253]: Added device '/dev/dri/card0' (nvidia-drm) using atomic mode setting.
gnome-shell[2253]: Device '/dev/dri/card1' prefers shadow buffer
gnome-shell[2253]: Added device '/dev/dri/card1' (amdgpu) using atomic mode setting.
gnome-shell[2253]: Created gbm renderer for '/dev/dri/card0'
gnome-shell[2253]: Created gbm renderer for '/dev/dri/card1'
gnome-shell[2253]: GPU /dev/dri/card0 selected as primary

old mesa

gnome-shell[2577]: Device '/dev/dri/card0' prefers shadow buffer
gnome-shell[2577]: Added device '/dev/dri/card0' (nvidia-drm) using atomic mode setting.
gnome-shell[2577]: Device '/dev/dri/card1' prefers shadow buffer
gnome-shell[2577]: Added device '/dev/dri/card1' (amdgpu) using atomic mode setting.
gnome-shell[2577]: Created gbm renderer for '/dev/dri/card0'
gnome-shell[2577]: Created gbm renderer for '/dev/dri/card1'
gnome-shell[2577]: GPU /dev/dri/card1 selected primary from builtin panel presence
User Icon sergiomb commented & provided feedback 2 months ago
karma

good experience with OpenGL version string: 4.6.0 NVIDIA 565.77 , also in chromeos with steam

BZ#2335454 mesa-24.3.3 is available
User Icon jexposit commented & provided feedback 2 months ago

@bitlord the component selecting the primary GPU is mutter, i happens here: https://gitlab.gnome.org/GNOME/mutter/-/blob/main/src/backends/native/meta-renderer-native.c?ref_type=heads#L2321

There is a rule in place that selects as primary the GPU connected to the laptop screen by checking if one of its connectors is eDP, LVDS ot DSI.

Could you check if drm_info returns different connector types between mesa versions?

For example, in my laptop, this is the connector used by the laptop screen:

├───Connectors
│   ├───Connector 0
│   │   ├───Object ID: 241
│   │   ├───Type: eDP

If possible, open a bug report in Mutter. I think it could be a good place to start fixing the regression.

User Icon frantisekz commented & provided feedback 2 months ago
karma

Works fine on Intel UHD (Gen 9 GPU)

User Icon bitlord commented & provided feedback 2 months ago

Thank you @jexposit, but no luck with drm_info, I have only one screen in both cases, internal laptop screen.

Diff of drm_info output has some differences for CRTC's and Planes (only on /dev/dri/card1 (in both cases integrated amdgpu)), and only connector with status connected is on the same card (amdgpu), same details :/

It's probably something specific for this hardware I have.

User Icon jexposit commented & provided feedback 2 months ago

@bitlord I was kind of expecting it, as that information is exposed by the kernel. It is still surprising that mesa is affecting the selected device as, in addition to the connector type, it only checks that the device is capable of hardware rendering.

As a workaround, you can add a udev rule to set the primary GPU: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1562

Some users suggest that this rule works better: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1562#note_2249922

I'd still suggest to create a bug report in Mutter so we try to find a proper fix.

User Icon niels-s provided feedback 2 months ago
karma
User Icon jexposit commented & provided feedback 2 months ago

FWIW, I documented the process here, hopefully it helps you selecting the desired GPU as primary while we find the issue: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4218

This update has been submitted for stable by leigh123linux.

2 months ago

This update has been pushed to stable.

2 months ago
User Icon cesarb commented & provided feedback 2 months ago
karma

After this update, totem no longer works, always giving a dialog box saying "Não foi possível inicializar o suporte a OpenGL" instead of playing the video.

User Icon sergiomb commented & provided feedback 2 months ago

did you reboot the machine after the update ?

User Icon cesarb commented & provided feedback 2 months ago

Yes, I did reboot, and just to make sure I rebooted again right now, still not working. I filled https://bugzilla.redhat.com/show_bug.cgi?id=2338414 with more details.

I also noticed a difference in the journalctl --user logs before and after the update: after the update, it now says "Failed to initialize accelerated iGPU/dGPU framebuffer sharing: Not hardware accelerated" for both cards (dGPU and iGPU), that message did not appear before (but nothing seems broken in gnome-shell, probably because it's already using the dGPU for both rendering and output, so it doesn't need framebuffer sharing).

User Icon decathorpe commented & provided feedback 2 months ago

FWIW, epiphany / GNOME Web also stopped working with EGL_BAD_ALLOC errors.

User Icon thetick commented & provided feedback 2 months ago
karma

Also note various Windows compositors like Hyprland, Miracle and Cosmic either crash or show a black screen due to EGL_BAD_ALLOC. Upstream mesa issue: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12467

BZ#2335454 mesa-24.3.3 is available
User Icon cesarb commented & provided feedback 2 months ago
karma

Totem is now working again after the following commands:

sudo dnf swap mesa-va-drivers-freeworld mesa-va-drivers sudo dnf swap mesa-vdpau-drivers-freeworld mesa-vdpau-drivers

User Icon jexposit commented & provided feedback 2 months ago

@bitlord are you using the mesa-freeworld (RPM Fusion) packages? Some users reported issues (https://bugzilla.redhat.com/show_bug.cgi?id=2338414) and I suspect that it could be your problem as well.

It is possible that the NVIDIA GPU is selected as primary not because of the connector type, but because an error is falling back to software rendering.

User Icon bitlord commented & provided feedback 2 months ago

@jexposit yes. I'm following all related issues, Fedora (RH Bugzilla), as well as RPMFusion. It most likely is, even with udev rule to force primary gpu, I also noticed that apps using webkit-gtk are broken, not displaying content of pages... as other mentioned. (but interesting is most things work with forcing my primary gpu, and work well, and fast as before, except webkit-gtk apps like epiphany, liferea (but interesting Evolution works, and renders messages (for which I think it also uses webkit-gtk))

Thank you!


Please login to add feedback.

Metadata
Type
unspecified
Karma
15
Signed
Content Type
RPM
Test Gating
Autopush Settings
Unstable by Karma
-3
Stable by Karma
disabled
Stable by Time
14 days
Dates
submitted
2 months ago
in testing
2 months ago
in stable
2 months ago
approved
2 months ago
BZ#2335454 mesa-24.3.3 is available
-1
3

Automated Test Results