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.
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.
@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.
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.
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).
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.
@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))
This update has been submitted for testing by jexposit.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'passed'.
Works for me..
This update has been pushed to testing.
This update can be pushed to stable now if the maintainer wishes
Works.
Ok except egl-utils, bug report, here : https://bugzilla.redhat.com/show_bug.cgi?id=2337082
Works great! LGTM! =)
Works
no regressions noted
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 -Bas well asnvidia-smiwhile in bios it was still set to hybrid graphics like before). And everything becomes really slow.Maybe there other updates as well with this combination that make it work like that, but if I only downgrade
mesatomesa-*:24.3.2-2.fc41.x86_64everything starts working normally again.Addition to my previous comment.
it is also visible from the log that nvidia is being used
new mesa
old mesa
good experience with OpenGL version string: 4.6.0 NVIDIA 565.77 , also in chromeos with steam
@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_inforeturns different connector types between mesa versions?For example, in my laptop, this is the connector used by the laptop screen:
If possible, open a bug report in Mutter. I think it could be a good place to start fixing the regression.
Works fine on Intel UHD (Gen 9 GPU)
Thank you @jexposit, but no luck with
drm_info, I have only one screen in both cases, internal laptop screen.Diff of
drm_infooutput has some differences for CRTC's and Planes (only on/dev/dri/card1(in both cases integratedamdgpu)), and only connector with statusconnectedis on the same card (amdgpu), same details :/It's probably something specific for this hardware I have.
@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.
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.
This update has been pushed to stable.
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.
did you reboot the machine after the update ?
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).
FWIW, epiphany / GNOME Web also stopped working with EGL_BAD_ALLOC errors.
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
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
@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.
@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!
mesa-freeworld updated with a fix.
https://download1.rpmfusion.org/free/fedora/updates/41/x86_64/repoview/mesa-va-drivers-freeworld.html