ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | Non-development talk: #asahi | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
drubrkletern has joined #asahi-dev
hightower2 has quit [Remote host closed the connection]
Urriellu has quit [Ping timeout: 480 seconds]
Hibyehello has quit [Read error: Connection reset by peer]
Hibyehello has joined #asahi-dev
raveling has joined #asahi-dev
drubrkletern has quit [Remote host closed the connection]
cylm has joined #asahi-dev
stipa is now known as Guest9642
stipa has joined #asahi-dev
Guest9642 has quit [Remote host closed the connection]
Urriellu has joined #asahi-dev
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<orowith2os>
without them in Flatpak format, there's no GPU acceleration for *any* flatpaks.
<orowith2os>
I have updating set up to follow the main Asahi Linux mesa updates; if a distro uses a different update cycle, they would have to provide their own Flatpak.
<orowith2os>
The intent here is to *only* support the main Asahi Linux kernel and Mesa.
<orowith2os>
so syncing userspace with the kernel isn't an issue, so long as you follow Asahi Linux updates *very* closely.
stipa is now known as Guest9649
stipa has joined #asahi-dev
Guest9649 has quit [Read error: Connection reset by peer]
Urriellu has quit [Ping timeout: 480 seconds]
seeeath has joined #asahi-dev
<dottedmag>
Flatpack isolation idea really breaks down with huge-GPU-piece-of-code-in-userspace situation.
<orowith2os>
*Flatpak, and not really.
<orowith2os>
by design, Flatpak can't really bring things in from the host; that's why it bundles the NVIDIA drivers. If the OS wants to provide a more-or-less glibc-version-independent driver, it can do so easily. But otherwise, there's no guarantee on ABI stability or drivers working.
<orowith2os>
For example, Steam brings in the drivers from the host, but that fails when the system isn't using glibc or it has to provide its own version of glibc.
<orowith2os>
Flatpak doesn't have an issue because it provides its own *stable* drivers
seeeath has quit [Ping timeout: 480 seconds]
<orowith2os>
Pulling in the host drivers also presents issues, particularly when architectures come into play. For something like Asahi Linux, it has to use emulation to run Steam, but Steam can't pull in the graphics drivers *because they're made with aarch64*
<orowith2os>
so you'd have to bundle an x86 version of Mesa
<orowith2os>
which Flatpak conveniently has full support for
<orowith2os>
as well as alternative arches emulation
nicolas17 has quit [Quit: Konversation terminated!]
eiln has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
orowith2os has quit [Remote host closed the connection]
<dottedmag>
Mesa is basically a GPU driver in userspace (among other things). NVidia userspace part is the same. This is the breakage I'm talking about: Flatpak has to take on a role of abstracting hardware, the role customarily reserved for OS kernel. For the most of the hardware kernel ABI is the interface, and userspace is more-or-less insulated from the vagaries of hardware. Not so with GPUs. In a microkernel design GPU driver would probably
<dottedmag>
be running as a separate isolated subsystem, not as a part of userspace program.
raveling has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
i509vcb has quit [Quit: Connection closed for inactivity]
raveling has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
nela5 has joined #asahi-dev
nela has quit [Ping timeout: 480 seconds]
nela5 is now known as nela
raveling has joined #asahi-dev
blasty has quit [Remote host closed the connection]
raveling has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
sefidel has quit [Remote host closed the connection]
sefidel has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
gabuscus_ has quit []
gabuscus has joined #asahi-dev
amarioguy has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
<marcan>
AIUI there is a way to bundle Flatpak runtime overlays with the OS. that is what would need to happen here, distributed as an Arch package.
<marcan>
it needs to be something I can build and push locally so I can push updates coinciding with mesa/kernel updates as we do for everything else
<marcan>
separate repositories won't work, that's a recipe for desync and user pain
kode54 has quit [Quit: Ping timeout (120 seconds)]
raveling has quit [Ping timeout: 480 seconds]
kode54 has joined #asahi-dev
raveling has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
<eiln>
marcan: was wondering how the ane stuff should proceed?
<eiln>
with the accel patches i can move in-tree
kettenis_ has joined #asahi-dev
kettenis has quit [Ping timeout: 480 seconds]
raveling has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
amarioguy has joined #asahi-dev
darkapex1 has quit []
darkapex has joined #asahi-dev
eiln has quit [Remote host closed the connection]
eiln has joined #asahi-dev
eiln has quit [Remote host closed the connection]
raveling has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
orowith2os has joined #asahi-dev
<orowith2os>
dottedmag: Flatpak does nothing of the sort. It just gives you the /dev device and, if you know how to communicate with it, you can do so. Everything else is handled by the kernel, including sandboxing features.
<orowith2os>
marcan: That won't work unless you follow a model similar to NVIDIA, where you build with the oldest known used glibc version and link to *only* that.
eiln has joined #asahi-dev
<orowith2os>
The Mesa package I have right now will keep in sync with the current updates, the only work that needs to be done is setting up a Flatpak repository.
<orowith2os>
I've put some thought into it, and agonized quite a bit over getting it to work. I'm confident in it working just fine.
<marcan>
orowith2os: I'm confused, how is the glibc version relevant exactly?
raveling has quit [Ping timeout: 480 seconds]
<orowith2os>
marcan: The Flatpak runtime includes a specific version of libc, in most cases older then Arch's (and alarm's). If you try to toss the native driver into Flatpak, you are going to run into glibc version errors, as well as llvm libraries and the like.
<orowith2os>
NVIDIA doesn't have an issue because it links against an older version, one that works with some of the oldest runtimes available
<orowith2os>
Asahi would need to do the same to achieve something similar
<marcan>
I think you misunderstood me. I'm saying we'd ship the same flatpak thing you're building, built the same way, just wrapped in an Arch package.
<orowith2os>
hmmm, maybe?
<orowith2os>
Want to give it a try?
<orowith2os>
I have something you can base it off of
<marcan>
there was a doc about this somewhere, it's intended exactly for this use case
<marcan>
something about distros being able to provide their own driver flatpaks like this
<marcan>
and then the other thing is just being able to run the build locally, both because everything else is like that and because you saw how the GH runners do :p
<orowith2os>
I'd like to make a quote from the article:
<orowith2os>
If you are a distro packager I do believe it makes sense to start making a nvidia package for the Flatpak extension especially for beta versions. This should probably not be used to package host versions of Mesa though because they link to host libraries outside of libc.
<orowith2os>
wait, still misunderstood
<orowith2os>
sorry
<orowith2os>
I thought you still meant building the driver on the host and mounting it in inside of Flatpak
<marcan>
I just mean on my own hardware
<orowith2os>
you mean building it inside of Flatpak, as intended, and shipping those binaries through the native package manager?
raveling has joined #asahi-dev
<marcan>
yes
<orowith2os>
I think that's doable
<marcan>
the goal here is that this way we *know* people get everything in sync with a pacman upgrade, which is the only sane way to survive the UAPI instability phase without users hating us
<orowith2os>
Makes sense
<orowith2os>
how do you want to handle builds?
<orowith2os>
Toss me some aarch64 runners for github, generate an archive, and the pacman package extracts and moves around those binaries?
<marcan>
as I said, ideally something I can run myself locally, end to end (flatpak side and pacman side)
<marcan>
even better if we can outright stick everything into our existing PKGBUILDs repo and duct tape it together :)
<orowith2os>
mmmm, I'd rather have the flatpak manifest in its own repo, for my own sanity
<orowith2os>
want to make a repo on the AsahiLinux org and push the current repo there?
<marcan>
well, for my own sanity I'd rather not have to push to even more repos every time I need to bump the version...
<jannau>
that can be an additional source for the mesa package
<orowith2os>
marcan: it'll update for you, all you need to do is update the PKGBUILD
<orowith2os>
Flathub has a bot go through all packages it hosts and updates them using that mechanism
<orowith2os>
the local workflows here do that too, on a similar schedule
amarioguy has quit [Read error: Connection reset by peer]
<orowith2os>
what I've been having trouble with is generating usable archives from the workflows
<marcan>
okay I see how that works but given I trigger everything myself anyway... doesn't it make more sense to just do it myself?
<marcan>
I assume there is some command I can run to trigger a build
<orowith2os>
when a commit is pushed, namely a mesa update, it'll build for you
<orowith2os>
you can also build it manually if desired
<marcan>
I know, but I only push commits to that branch when they're ready for release, and we also have a dev repo and we need to keep the flatpak stuff following the same pattern
<marcan>
I mean this automagic pull stuff makes sense when it's a third party doing one side, but in this case I want to be in charge of both sides
<orowith2os>
We can make a separate branch for dev
<marcan>
so there isn't much point to having an automatic checker in the loop
raveling has quit [Ping timeout: 480 seconds]
<orowith2os>
if you have a dev PKGBUILD I can base a workflow off of, that would work just fine. Or, if everything's local, point toward a specific source URL for Mesa
raveling has joined #asahi-dev
<marcan>
it's the dev branch on the PKGBUILDs repo
<orowith2os>
oh yeah this is doable
<marcan>
stuff just gets synced from there to the main repo once I'm happy that it's in a good state
<orowith2os>
just make the update workflow check a dev branch, and change the URL it searches
<orowith2os>
want me to get on that?
<marcan>
okay but as I said, doesn't it make more sense for me to trigger these builds somehow from the PKGBUILD that will ship them, instead of all this checker/pull stuff?
<marcan>
like I just want to know how to run a build locally myself
<orowith2os>
You can build the Flatpak by running a command like this: `flatpak-builder --user --install --force-clean build-dir org.irssi.irssi.yaml`
<marcan>
then I can plug that into a PKGBUILD for mesa-asahi-edge-flatpak or something, and we tell people to install that for flatpak support, and that's thaat
<marcan>
*that
<orowith2os>
Is there a way to trigger a workflow from another git repository?
<marcan>
probably with some webhook mess? but right now I just run everything locally anyway
<marcan>
don't want to complicate things too much :p
<jannau>
ideally this would not involve github in any way
<marcan>
yeah
<orowith2os>
That's that the x-checker-data does, though?
<marcan>
especially since there's a good chance stuff is going to move to gitlab over time anyway
<orowith2os>
If it searches often enough, or has a webhook trigger, the flatpak will update whenever the PKGBUILD is
<jannau>
sigh
<orowith2os>
I'm probably misunderstanding
<orowith2os>
it's easier when I have something to base off of
<marcan>
none of this should involve github, it should just be another PKGBUILD I can just makepkg which itself invokes the flatpak-builder command (and hopefully there is some way of passing the version via environment/arg so we don't need to keep updating those files)
<orowith2os>
OH
<jannau>
the flatpak is ideally build on the same system as the asahi linux PKGBUILDs without involvment of any github workflow
<orowith2os>
yeah, that can be done
<orowith2os>
point the flatpak manifest toward the git repo that the PKGBUILD clones and whenever you build the PKGBUILD, it'll update the flatpak too
<marcan>
is there a way of interpolating a variable in there?
<marcan>
like from the environment or an argument or something
<orowith2os>
You can't take in variables from outside the build env, no
<marcan>
sigh, okay, then it'll be sed games in the PKGBUILD or whatever
<marcan>
still doable
<orowith2os>
but what you *can* do is clone asahi/mesa to the normal PKGBUILD clone directories and point the flatpak towards the local directory
<marcan>
oh like pre-extract it?
<orowith2os>
yeah, whatever the PKGBUILD uses, the flatpak will too
<marcan>
and then how is sources: laid out?
<orowith2os>
you see the current sources, where it has a git url, checksums, etc?
<orowith2os>
there are other source types, namely `dir`
<marcan>
yes
<marcan>
ok, I can work with that
raveling has quit [Ping timeout: 480 seconds]
<marcan>
and then how is the actual flatpak versioned? like is there metadata that has to contain the version somewhere?
<orowith2os>
you don't strictly have to have the metadata outside of flathub
<orowith2os>
it's allowed to just neglect it
<marcan>
ah, then for the host stuff it doesn't matter
<marcan>
ok
<marcan>
then that should work
<orowith2os>
keep in mind you'll have to build the flatpak for every branch of the freedesktop runtime
<orowith2os>
only the currently supported ones
<orowith2os>
21.08 and 22.08
<marcan>
older builds can't run against the new one?
<orowith2os>
not without risking ABI breakage
<marcan>
define "risking"
<orowith2os>
what does asahi/mesa link against?
raveling has joined #asahi-dev
<orowith2os>
if it were to link against glibc.so, and the ABI changed from 21.08 to 22.08 in a breaking way, the flatpak would be broken. That's what I mean by risking breakage
<orowith2os>
something like NVIDIA doesn't have an issue because it links to glibc.so and *only* glibc.so, and an old one at that
<marcan>
glibc doesn't break ABI
<orowith2os>
theoretically, if it did
<orowith2os>
that's the situation we'd have on our hands
<marcan>
theoretically, if it did, the world would ~explode
<orowith2os>
can't say you're wrong
<marcan>
other libs break ABI all the time, glibc certainly does not, they have all kinds of versioned symbol stuff for that
<orowith2os>
back to my previous question: what does asahi/mesa link against?
<marcan>
looking into that
<jannau>
llvm might be a problem
<orowith2os>
oh, no, that'll be fine
<orowith2os>
read the manifest again
<orowith2os>
at the end, it copies the LLVM library to the driver
<marcan>
libexpat, libz, libzstd, libsensors, the rest is glibc/compiler stuff and such
<marcan>
libexpat makes sense, libsensors I have no clue why, maybe we can turn that off
<jannau>
libsensors is not needed
<marcan>
oh it's the gallium HUD...
<orowith2os>
if ABI stability is guaranteed for the libraries, we'll be fine. If not, drag em into the extension and pray for the best.
<marcan>
yeah we can turn that off
<orowith2os>
okay, so now that the ABI is out of the way
<marcan>
I don't think ABI stability is "guaranteed", but libstdc++ already learned the breaking ABI lesson, and the others are .1 versions which tells me they're not fans of breaking ABI
<marcan>
except libsensors, but I'm pretty sure we can turn that one off
<orowith2os>
how do you want to handle multiarch?
<marcan>
I have no idea :p
<marcan>
none of that is really worked out yet
<marcan>
we need multiarch for the native driver too
<orowith2os>
aarch64 can easily be provided, but I made the flatpak with the express intention of supporting x86
<orowith2os>
it builds on x86, at least
<marcan>
it's entirely possible the answer will be "we won't, until fedora, and call it a fedora perk" because exploding combinatronics are no fun and we are going to be moving wholesale to fedora as the main supported distro anyway
<orowith2os>
Flatpak also has built-in support for binfmt_misc, so it can make an x86 environment to build in
<marcan>
but ultimately whatever we do for host-side multiarch will have to involve host-side x86 packages and then the flatpak stuff can just tag along the same way in that environment
<orowith2os>
good enough
<orowith2os>
you'll have to add qemu and the like as a dependency to the PKGBUILD unless you can manage to run the builds on a mix of aarch64 and x86
<marcan>
I suspect it'll just be outright x86 runners for x86 stuff
<marcan>
I do have a threadripper that's going to be very idle once I stop daily driving gentoo :p
<orowith2os>
can you split a PKGBUILD into different sections for different runners, like a mixed x86<->aarch64 PKGBUILD?
<marcan>
the same PKGBUILD can be used on multiple arches and if you must you can check for the arch
<marcan>
then you just build it once on every arch
<marcan>
but there are a bunch of other questions to be asked there because the use case for this is FEX and FEX requires funny things to build a rootfs and yada yada
<orowith2os>
works for me, the core Mesa stuff can be disabled on x86 anyways
<marcan>
so now is not the time to answer that question
<marcan>
core mesa?
<orowith2os>
the native libs
<marcan>
I'm confused, the x86 packages should be 1:1 with the arm64 packages
<marcan>
we need native libs for both
raveling has quit [Ping timeout: 480 seconds]
<orowith2os>
only for Flatpak, unless you want to support the Asahi driver on x86 outside of Flatpak too
<marcan>
we do
<marcan>
that's kind of the point
<orowith2os>
ah, alright
<orowith2os>
x86 will need one extra patch file, for 32-bit support
<orowith2os>
we're a bit blocked on an upstream issue
<marcan>
orowith2os: either way the layers involved in steam stuff on FEX on x86 make me unclear on whether the flatpak stuff is even going to make sense, so let's punt on all that until the whole thing is clearer
<orowith2os>
mmmmmmm, I really don't wanna
<orowith2os>
~~I've been doing everything so far from an x86 machine~~
<marcan>
I'm saying let's ignore x86 for now :p
<orowith2os>
the only arm systems I have right now are my raspberry pis
<marcan>
yeah but you can't exactly use this driver on an x86 machine anyway
<marcan>
its only use case is for emulated environments
<orowith2os>
you can't use the *asahi* driver
<orowith2os>
when this was starting out, I ran it on CPU renderers
<orowith2os>
to be sure it was packaged correctly and all
<marcan>
sure
<marcan>
but the use case is arm64 :p
<orowith2os>
alright, I'll get on making some build scripts
<orowith2os>
where does makepkg store the sources?
<orowith2os>
relative to the PKGBUILD directory
<marcan>
src/
<orowith2os>
so the Mesa source would me src/mesa?
<marcan>
src/mesa-asahi-$_asahiver
<marcan>
also the $PWD is src/ when the prepare() / build() functions run
<orowith2os>
grrrr
<orowith2os>
I'll have to figure out how to get $_asahiver in there
<marcan>
or just make a symlink in the PKGBUILD...
<orowith2os>
that would be nice
<orowith2os>
src/mesa to src/mesa-asahi-$_asahiver
<marcan>
yeah so just do that :p
<Foxboron>
Whats the issue?
<orowith2os>
We're trying to sort out Flatpak support in the Asahi driver
<Foxboron>
if you want to rename the source location, you can do that in the source=() array
seeeath has joined #asahi-dev
raveling has joined #asahi-dev
leeaster has joined #asahi-dev
leeaster is now known as baahemian
<orowith2os>
marcan: can you hop over onto Matrix for sorting out the Flatpak stuff? I still need to set up a proper IRC client and I'd like to share stuff like code blocks more easily.
<marcan>
it's midnight here, I'm about to crash, and I'd prefer to keep discussion here since here is where the community is
<orowith2os>
alrighty
<marcan>
this isn't going to be very complicated anyway, if you can give me some flatpak yaml that can build the flatpak out of some relative directory of your choosing I can deal with the PKGBUILD side
<orowith2os>
I'll push it to a branch you can clone
<marcan>
ideally also tell me what arch/ALARM packages I need as dependencies to do all this (flatpak-builder))
<orowith2os>
oh yeah I'll have checks for all those in a build script too
<kettenis_>
marcan: the device tree floating-point is annoying since it means I can't build the asahi-wip device trees for testing with u-boot and OpenBSD anymore
<marcan>
kettenis_: sounds like you're in a great position to start pushing through the float support then! :D
<kettenis_>
I also have the feeling that this idea is going to meet some significant resistence
<marcan>
yeah well it's either this or we start putting binary float32 hex constants in the DT which is worse
<kettenis_>
floating-point in kernels is problematic
<marcan>
that is already taken care of, it's softfloat
<marcan>
only dtc cares
<marcan>
the kernel itself never uses floats
<kettenis_>
I'm not talking about Linux
<marcan>
the firmware wants floats
<marcan>
good luck not doing floats
<kettenis_>
ugh
raveling has quit [Ping timeout: 480 seconds]
<marcan>
hey lina pulled off softfloat in a couple hundred lines of rust and it's all operator overloaded and nice and ergonomic
<marcan>
oh right, you want to do it in C :D
<marcan>
just be glad m1n1 is taking care of the calculations involving exponentials (yes there's some of those those too)
raveling has joined #asahi-dev
<kettenis_>
I don't think you want me to push for something that I'm not certain is a good idea ;)
<marcan>
feel free to come up with a better one ;)
<kettenis_>
can these just be uint32_t placeholders that get filled in by m1n1
<kettenis_>
?
<marcan>
no, only some of those are dynamic, m1n1 doesn't know the per-model values
<kettenis_>
I suppose that makes experimentation harder
<marcan>
in fact the dynamic stuff m1n1 fills in isn't even floats (though it is computed using floats)
<marcan>
I mean nothing stops you from replacing all the floats with the equivalent uint32 representations, it will work the same
<marcan>
it'll just be a royal pain to make any changes
<marcan>
those numbers in the DTs are pretty much 1:1 from Apple's DT
<marcan>
AIUI that's on purpose, to make porting over new devices less of a pain
baahemian has quit [Quit: baahemian]
<kettenis_>
if they 1:1 match Apple's DT, m1n1 could copy them over
baahemian has joined #asahi-dev
<marcan>
in principle yes, I guess
<marcan>
but that violates the principle that this is static data for any given device
<marcan>
and m1n1 only copies dynamic data
raveling has quit [Ping timeout: 480 seconds]
<kettenis_>
still something to consider; easier to change your own principles that that of others ;)
raveling has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
zkrx has quit []
cylm has quit [Remote host closed the connection]
raveling has joined #asahi-dev
zkrx has joined #asahi-dev
user982492 has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
seeeath has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
user982492_ has joined #asahi-dev
raveling has joined #asahi-dev
user982492 has quit [Ping timeout: 480 seconds]
raveling has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
orowith2os has quit [Remote host closed the connection]
<marcan>
eiln: since I forgot to answer, before I go to sleep: feel free to move in-tree, that's where we want to be anyway. you can prepare a branch based on asahi-wip and I can rebase it into one more bits/ branch. we can enable it in actual asahi-dev then asahi builds whenver you think it's usable/worth having people test.
<marcan>
ANE is very much a "side" thing right now so I'm comfortable leaving things up to you, I doubt it's going to become a critical piece of the ecosystem overnight (which is a good place to be when developing since you don't have to care about users as much :p)
raveling has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
seeeath has joined #asahi-dev
bcrumb has joined #asahi-dev
bcrumb has quit []
seeeath has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
seeeath has joined #asahi-dev
derzahl has joined #asahi-dev
seeeath has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]