remove mesa-asahi-edge#303
Conversation
|
Are we ready to say goodbye to this? I think Fedora is continuing to keep the custom Mesa around for future development, but the upstream Mesa enablement allows compatibility in VMs etc. I think it would be better to fix it. |
|
I agree with @tpwrules until fedora switches we shouldn't either. They clearly still think diverging from upstream is worth it. |
|
Gentoo for example only plans to keep mesa around in their overlay until I'm not entirely what/why Fedora is planning to do (maybe it needs to be orchestrated more carefully there?), but I'd assume in a few months from now things will just end up in mainline mesa, and their custom mesa package will disappear too. I'm happy to keep this PR open for a while until the dust has settled. |
|
This would immediately break stable which would be really unfortunate so let's not. The fix turns out to be simple, @wistfulbrick 's fix appears right. On the other hand, the Asahi Linux distro guidelines do not call out Asahi's Mesa fork as needing to be packaged so perhaps we can drop this sooner than I thought. |
|
According to Conan Kudo on Matrix, the next Fedora version will switch to upstream mesa (and Rawhide has already made the switch). However, this did break the emulation stack as mentioned above. It might be best to hold out as @flokli suggested until the dust settles. |
flokli
force-pushed
the
mainline-mesa
branch
4 times, most recently
from
12d5811 to
ec1abe3
Compare
|
I think the virglrenderer MR is at https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1527. |
|
Now that Mesa 25.2 has been released with Asahi virtio support enabled, and Fedora Asahi is moving towards using upstream, I think it's time for this to be included. |
ghost
mentioned this pull request
|
Mesa 25.2 has landed in |
Is this included in the pin at #330? |
|
I think it just got barely missed. We need to do a release both for stable and unstable first though. I am preparing those now. |
ghost
mentioned this pull request
|
Rebased, and |
|
I still need to test this. |
|
Is this dependent upon the kernel upgrade? Would prefer to keep that as a separate PR. |
No, the switch to the uapi that was also upstreamed happened a while ago the kernel is already up to date enough. I'm just stupid and pushed these commits too while rebasing, will update 😆 Edit: done |
|
This PR works for me. |
|
Hi, just to let you know that I tried this PR on my m2 air. And for me it looks broken. I spot it quickly just opening a youtube video. Its laggy. |
That is probably the known Hyprland OpenGL bug with Mesa 25.2, see here. |
I'm using sway now, not hyperland anymore. |
And it's still an issue, or not an issue anymore? |
I sadly dont know what is the root cause, mesa related for sure, but yes, its not usuable anymore for me it this get merged as this. |
|
I use the Hyprland patches suggested by another user in #340 with mesa 25.2, but it still runs on These patches are the ones from a Hyprland PR that is supposed to fix this problem. |
|
Can it be we need both last kernel and mesa to get all thing working ? You said previously @flokli you test only on last kernel true ? Your other PR ? |
I tried using #326 to update kernel, but that didn't work either. To be clear I didn't use this PR, I just set |
|
Okay just upgraded my nixpkgs (2025-08-19) in my nixos configuration on a branch with this patch applied and now I'm suddenly in llvmpipe even though I'm on 25.2 and on GNOME (setting relevant vulkaninfo output: Device Properties and Extensions:
=================================
GPU0:
VkPhysicalDeviceProperties:
---------------------------
apiVersion = 1.4.318 (4211006)
driverVersion = 25.2.0 (104865792)
vendorID = 0x10005
deviceID = 0x0000
deviceType = PHYSICAL_DEVICE_TYPE_CPU
deviceName = llvmpipe (LLVM 19.1.7, 128 bits)
pipelineCacheUUID = 32352e32-2e30-6161-6161-616161616161
I don't know if this is a kernel issue or an upstream (nixpkgs) mesa regression. |
Can you check my |
|
On my m2 when it
I will try, with a friend we fork and merge your two branches somewhere. I try to build now, as unlucky boy I just got ratelimited by github 😄 Building now... |
|
I think I can say that it's something with newer versions of nixpkgs and related to the kernel. diff --git a/flake.lock b/flake.lock
index bd565fa..d728fb1 100644
--- a/flake.lock
+++ b/flake.lock
@@ -101,11 +101,11 @@
},
"nixpkgs": {
"locked": {
- "lastModified": 1755615617,
- "narHash": "sha256-HMwfAJBdrr8wXAkbGhtcby1zGFvs+StOp19xNsbqdOg=",
+ "lastModified": 1755186698,
+ "narHash": "sha256-wNO3+Ks2jZJ4nTHMuks+cxAiVBGNuEBXsT29Bz6HASo=",
"owner": "nixos",
"repo": "nixpkgs",
- "rev": "20075955deac2583bb12f07151c2df830ef346b4",
+ "rev": "fbcf476f790d8a217c3eab4e12033dc4a0f6d23c",
"type": "github"
},
"original": {The removal lines are for 2025-08-19 and the addition lines are for 2025-08-14 in my nixos configuration's |
|
I can confirm what @normalcea says about it must be related to nixpkg version... I saw same behavior, but did not have time to look at it. Also I can confirm the @flokli wip branch should work fine my main is almost same and it is what I am using now on M2 pro. |
|
I had the same issue @normalcea and rolled back to a nixpkgs version from early July, and it works for fine. I haven't gotten the chance to test the |
Early July is not mesa 25.2 though (just saying because with Hyprland for example the problem is supposedly with mesa 25.2, though I have it even with the PR that is supposed to fix it). Both versions that normalcea tried with gnome (one working, the other one not) are mesa 25.2. |
No luck. Before, working: After, with wip branch: |
I don't know if this would help but I found this issue on the Mesa GitLab repo. issues#13746 So I think just rolling back nixpkgs for now should work. |
I can confirm that using |
Also confirm
@ToborWinner: I found I don't even need the patches suggested there anymore (i.e. changes from hyprwm/Hyprland#11087) - also works with vanilla hyprland from rev |
|
Did a git bisect on nixpkgs from the revisions I gave above I think the culprit is This is a listed breaking change in 25.11, so I think this is more reason to start moving to full NixOS kernel builds sooner than later. The commit before these changes is |
|
If any of you could try it with github:yuyuyureka/nixos-apple-silicon/minimize-patches, that branch provides a full NixOS kernel (and also removes mesa-asahi-edge). |
My last evening test, pinning nixpkgs to GPU is recognized, but I just open randomly zeditor, and I can see the famous pinky artifacts, so, it's better but still buggy in another way. |
Pinky artifacts in zeditor too, but gpu detected, btw, its tooks maybe 4x more times of building compared to "optimized" kernel as we build all modules i think. |
Thanks for the bisect @normalcea 🙏
@yuyuyureka: I tried this, but GPU wasn't recognized if I also used latest nixpkgs. Rebuilding now with revert of NixOS/nixpkgs#423933 - just takes quite some time. (UPDATE: can now confirm your branch with full NixOS kernel works if also reverting NixOS/nixpkgs#423933) |
|
So there is absolutely no relation between the breakage we've been observing with Rust not being detected in the Linux build, and removing mesa-asahi-edge. If there are no more concerns related to this, I would like to merge it soon. |
tpwrules
left a comment
tpwrules
left a comment
There was a problem hiding this comment.
Thanks for the improvements. Tested again and working for me.
Let's fix the driver build before cutting a new release.
11 participants
Since mesa 25.1, support for asahi is enabled by default. This means,
the nixpkgs mesa is sufficient and we don't need any custom mesa, or
methods to replace it.
In addition to the now ineffective
hardware.asahi.useExperimentalGPUDriver option, this also removes the
hardware.asahi.experimentalGPUInstallMode option, which was already
deprecated before.
Fixes #338.