-
-
Notifications
You must be signed in to change notification settings - Fork 14.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mesa: 23.0.3 -> 23.1.1 #233220
mesa: 23.0.3 -> 23.1.1 #233220
Conversation
Yes, we've been avoiding |
@ofborg build mesa_23_1 |
Mesa 23.1.1 available now: https://lists.freedesktop.org/archives/mesa-dev/2023-May/226012.html Was wondering if we should build Mesa with LLVM 16 now that we have it? |
@ofborg build mesa |
# does not make any sense | ||
"-Dandroid-libbacktrace=disabled" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I'm not really a fan of that comment tbh because it makes a statement without any explanation/reasoning.
I assume android-libbacktrace
is only useful for / only makes sense on Android?
Something like "# Only useful on Android:" would be a bit better IMO (but the current comment should be fine as well as android
is in the name of the flag).
Makes me wonder why it's enabled by default though (is it even enabled on more platforms than aarch64
?). Would be interesting if there's an upstream issue regarding this. (The Arch package sets that flag as well FWIW: https://gitlab.archlinux.org/archlinux/packaging/packages/mesa/-/blob/main/PKGBUILD)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Upstream has heuristics for enabling things that make sense on the platform where it is being built.
However we (and arch too?) use the meson auto_features
flag (enabled by default in the meson setup-hook) which tries to automatically enable all possible flags.
I also ran into this when attempting to build on darwin, because there it enables lots of features that don't make sense on darwin.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, that makes sense, thanks for the explanation! :)
IIRC newer LLVM versions are often required for additional features. Would be best if we had some more information on this for the current case of LLVM 16 though (as motivation for bumping the LLVM version). |
BTW we can build mesa 23.1 for darwin with |
I'm not sure it is. It's not like we're getting any hardware acceleration out of Mesa on Darwin anyway. |
disabling |
Can we just go back to a single default.nix for mesa now? |
Is the cpio commit here by mistake? |
yes |
qt5.qtmultimedia -> gst-plugins-base -> libGL is a channel blocker for darwin |
@ofborg build gst_all_1.gst-plugins-base gst_all_1.gst-plugins-bad gst_all_1.gst-vaapi |
@ofborg build gst_all_1.gst-plugins-base gst_all_1.gst-plugins-bad gst_all_1.gst-vaapi SDL2 |
✅ fixed evaluation of the |
Remaining mesa reverse dependencies on Darwin:
|
Maybe we can fix try fixing wxwidgets, the rest seems highly libgl specific. |
I have tested locally that |
] ++ lib.optionals haveWayland [ wayland wayland-protocols ] | ||
++ lib.optionals stdenv.isLinux [ libomxil-bellagio libva-minimal udev ] | ||
++ lib.optionals stdenv.isDarwin [ libunwind ] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
libunwind was darwin-only and you made it unconditional. Was that intentional/required?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this change was required to make it build
@wegank sorry but I already spent tens of hours booted in mac OS which made my wrists hurt, just to maintain something I will never use. We had several discussions in matrix and opened #233265 a week ago hoping that someone from the darwin team would engage, but nobody did. I even created a hack that would have made mesa 23.1 build on darwin, but this was considered too invasive by other contributers (e.g. "if it this fucked up it should be fixed upstream"). When we send emails to 56 people and nobody reacts at all after 8 days, I'd assume that a) nobody cares about mesa on darwin or b) nobody wants to put in time, and the conclusion from both is it's not sustainable to keep this around. |
23.1.2 released. |
Already in staging-next. |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/dont-understand-mesa-and-python-overlays-in-my-flake/32154/3 |
Description of changes
I remember something about.0
releases being not considered stable, so this is a draftThings done
sandbox = true
set innix.conf
? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)