marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
doggkruse has joined #asahi
robinp has joined #asahi
doggkruse has quit [Ping timeout: 480 seconds]
chadmed has joined #asahi
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
nskl has joined #asahi
nsklaus_ has quit [Ping timeout: 480 seconds]
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
kov has quit [Quit: Coyote finally caught me]
kov has joined #asahi
everslick_ has quit [Remote host closed the connection]
everslick_ has joined #asahi
<marcan>
nobodynada: are you interested in any particular aspect?
<marcan>
it's pretty much pick something that piques your interest and roll with it (e.g. how povik just picked up audio)
<marcan>
I think we have a bunch of kernel newbies around, so that's no big deal :)
<marcan>
kernel programming isn't particularly strange as far as systems programming goes, you get used to the style fairly quickly
<marcan>
of course there's also plenty of room for testing, writing docs, etc :)
skali has joined #asahi
skali has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sven>
yeah, if you know systems or similar low-level programming it's just a matter of getting used to how the kernel and the development process works
<j_ey>
You can also already start getting / building the kernel + m1n1
<j_ey>
(if thats also new to you nobodynada!)
<povik>
alyssa: thanks!
<povik>
although the commit hashes still dont seem to match
<povik>
no worries, i will match by messages then
nskl has quit [Ping timeout: 480 seconds]
<povik>
does linux really need to put a license-identifier on a makefile which is basically a file listing?
<povik>
is this to appease some automatic tree-wide check?
Nspace has joined #asahi
Nspace has quit [Quit: Nspace]
<povik>
working in linux repo i cant specify just 6 characters of commit hash like i am used to :O
<povik>
16**6 / 1_000_000 = 16.78
<povik>
checks out
<maz>
povik: we had to bump up the default to 12 a while ago.
<marcan>
now I can largely just make all the review feedback changes in my working tree, run that and rebase -i, and be done with the next version
<povik>
marcan: nice find!
<nobodynada>
marcan: cool, thanks! I don't have any particular area of interest right now, but I suppose I can get it booting, poke around to learn how stuff works, and then pick something to work on
<nobodynada>
it'll probably be a fair bit of work until an M1X even boots, won't it? like it'll at least need new device trees and chicken bits and stuff
VinDuv has joined #asahi
nskl has joined #asahi
<marcan>
yeah, though expect a nice bring-up stream the day mine arrives :)
<marcan>
tbh we can probably get it booting to a terminal in a day
<marcan>
unless something really radical changed
<marcan>
mostly just new DTs, adding chickens to m1n1, fixing any hardcoded device issues (e.g. if UART0 moved), and driver changes where incompatible changes happened
<chadmed>
only real difference for bring up _should_ be more firestorm cores afaik. i sincerely doubt apple will bother changing anything else that does not need to be changed, especially given their knack for maintaining hardware compatibility
<marcan>
depends on whether this is the "M1X" or the "M2", but yeah
<marcan>
assuming it's the "M1X" then it's probably largely compatible
<marcan>
that said, there's rumors of multi-die stuff which might be... interesting
<marcan>
depending on how that's implemented
<marcan>
might end up being the first NUMA ARM64 laptop? :p
<chadmed>
yeah im talking just "M1X" here. pretty sure M2 will be blizzard/avalanche replacement for the M1
<nobodynada>
makes sense! I should have been in bed 4 hours ago so I'm going to sign off for tonight, but thank you and I hope I can be at least somewhat useful :)
<nobodynada>
I've been astounded by the rapid progresss you all have been making, and this sort of low-level programming is sort of an aspiration of mine so I'm super excited for the opportunity to learn & contribute
<nobodynada>
Take care
nobodynada has quit [Quit: leaving]
<sven>
marcan: autofixup looks incredibly useful!
<povik>
woo! dcp driver works swell here
<povik>
firefox doesn't exactly like the audio driver
<povik>
there's something wrong with the driver reporting back the playback progress
<povik>
sound works, but video doesn't start
<povik>
interesting how it works while obviously being broken :)
<marcan>
so apparently there's this *other* performance config framework called "interconnects" intended for memory bandwidth and such
<marcan>
and OPP also interops with that
<marcan>
so I guess *that* is what the memory controller should use?
<marcan>
... but that means I now need memory bandwidth numbers if I don't want to fake it
<marcan>
I guess I'll have to run some m1n1 tests...
<marcan>
alyssa: did you have the DISP0 regs handy somewhere? I want to just kill the framebuffer in m1n1 (to remove it from the bandwidth equation for testing)
<marcan>
I guess I could probably just powergate DISP0, lol
<j_ey>
stream? ~_~
<kettenis>
it'd be a black screen ;)
<j_ey>
calming :D
<kettenis>
marcan: seems you have bitten off quite a big chunk with that cpufreq/mmc work
<kettenis>
s/mmc/mcc/
<povik>
found the culprit, firefox happy now
<j_ey>
povik: something in your code?
<povik>
yeah, would be very surprised if it wasn't :-p
<povik>
celebrated a bit too soon, still doesn't work perfectly
<povik>
isn't the hypervisor messing with time?
<chadmed>
povik: yeah today went really slowly for me, guess marcan's messing with some code :P
<povik>
:D
<povik>
everyone hop onto the marcan-blaming time
<povik>
i mean, train
<chadmed>
git blame marcan
<povik>
chadmed: well there's literally a variable called stolen_time in hv code
<chadmed>
povik: i might be wrong (im really stupid) but i think that is to mark the time the cpu was stolen from the m1n1 guest
<povik>
yeah i think so too
<povik>
anyway sound in firefox works ok outside of hypervisor
<chadmed>
via pulse/pipewire?
<chadmed>
or straight to alsa?
<povik>
i think this is straight to alsa, let me check
<povik>
there's pulseaudio running, this is some default debian setup
<chadmed>
itd be through pulse then yeah
<chadmed>
i actually dont think ff is capable of sinking direct to alsa
<marcan>
povik: ah yes, I would not be at all surprised if the HV breaks the passage of time
<marcan>
I think to do this properly requires paravirtualized shenanigans
<marcan>
might be worth implementing :)
<marcan>
I didn't particularly care for now, but if we're doing audio it starts mattering...
<marcan>
povik: you can undefine TIME_ACCOUNTING at the top of hv_exc.c and try
<marcan>
if that works I should just make it runtime configurable
<marcan>
it's important when running macOS because otherwise timeouts happen
<marcan>
(when certain MMIO is hooked)
<povik>
i don't think the hv is that important for debugging audio
<povik>
triggered only few crashes so far
<marcan>
fair
<povik>
otherwise i can run outside of hv, and if i run in hv, i now know not to pay attention to stuttering
<povik>
so it does not seem important to have that implemented
<marcan>
sure, but if undefining that is an easy fix, might as well just make it a flag :)
<alyssa>
povik: glad to see DCP driver is useful :-p
<alyssa>
marcan: don't know the DISP0 reg to kill the framebuffer the right way. powergating is probably easier.
<marcan>
fair
<alyssa>
marcan: otoh I am interested in the relevant DCP stuff
<alyssa>
for DPMS
<marcan>
going to stream more MCC / cpufreq shenanigans in a bit (#asahi-stream)
marvin24 has joined #asahi
marvin24_ has quit [Ping timeout: 480 seconds]
aleasto has joined #asahi
<povik>
marcan: turns out sound works alright in hv if all driver bugs are fixed
<povik>
so we can postpone doing anything about TIME_ACCOUNTING
<marcan>
lol
<povik>
alyssa: it is! i can watch seinfeld episodes on my mac mini now :-p
<alyssa>
povik: :-p
jbowen has joined #asahi
yuyichao_ has quit [Ping timeout: 480 seconds]
jmr has joined #asahi
jmr has quit [Remote host closed the connection]
jmr2 has joined #asahi
jmr2 has quit [Remote host closed the connection]
yuyichao_ has joined #asahi
psykose has quit [Remote host closed the connection]
psykose has joined #asahi
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi
yuyichao_ has quit [Ping timeout: 480 seconds]
bps has quit [Ping timeout: 480 seconds]
yuyichao_ has joined #asahi
yuyichao has quit [Ping timeout: 480 seconds]
<sorear>
would m1x or m2 have aicv2?
<sven>
your guess is as good as mine
<ar>
we won't know until first devices ship to someone who knows how to check for this stuff
jbowen has quit [Remote host closed the connection]
jbowen has joined #asahi
<marcan>
so apparently that dramcfg thing is almost entirely bullshit, lol
<marcan>
so far I found one geekbench subtest where it shows a ~8% performance gain, and I'm not so confident about it not being just noise
<marcan>
the overall scores are within 1% or so
<j_ey>
is that part of the mcc stuff youve already done or something else?
<marcan>
yes, the mcc stuff I already did
<marcan>
seems it is mostly useless
<j_ey>
:/
<marcan>
(I was going to redo it on the stream today, but I wanted to get bandwidth numbers... spent a ton of time learning that apparently the M1 is *50% slower* doing memory ops if you unroll more than 4 stp/ldp per iteration?!)
<marcan>
(then after that it turned out the bandwidth was the same either way, including on macos)
<sven>
weird
Nspace has joined #asahi
yuyichao has joined #asahi
yuyichao_ has quit [Ping timeout: 480 seconds]
Nspace has quit [Quit: Nspace]
Nspace has joined #asahi
Nspace has quit []
houlton[m] has joined #asahi
<landscape15[m]>
marcan: Maybe it's a stupid question, but i'm curious to know why you are using Python to develop the asahi-insaller.
<j_ey>
landscape15[m]: why not?
bps has joined #asahi
<landscape15[m]>
Well, I would use C because it's more "friendly" with the hardware and there are useful libraries.
<alyssa>
useful libraries? for C?
<j_ey>
it's an installer!
<j_ey>
it's just twiddling some things, running some commands
<psykose>
what does 'friendly with the hardware' mean
<psykose>
is this an elaborate meme
jbowen has quit [Quit: leaving]
<landscape15[m]>
alyssa: I mean that it wold be easier to implement in a GUI application.
<landscape15[m]>
*would
<alyssa>
easier to implement a GUI application? C?
<j_ey>
landscape15[m]: the installer is more of a pre-installer for a distro
<psykose>
alyssa: i think this is a secret hush hush version of c they don't tell us about
<mjg59>
landscape15[m]: The Fedora GUI installer is written in Python. There's no need to use C for this kind of thing.
<alyssa>
hi mjg59
<sven>
C and easy to implement :D
<sven>
maybe i learned the wrong kind of C
<landscape15[m]>
mjg59: Yes i agree. It's only that i don't like a lot how Python works. I'm more a Java fan for the GUI
<sven>
we'll happily make a java (or whatever) gui installer the default if someone implements and maintains it
<landscape15[m]>
sven: Yeah but as you said it's more a pre-installer. The good part comes after.
<psykose>
what case are you making other than 'i dont like python'
<sven>
on a more serious note, languages are tools. they all suck in one way or another.
<sven>
and for an installer it really doesn't matter what language it's implemented in
<psykose>
yep
<landscape15[m]>
psykose: It's only a prejudice. I usually think at Python as an ML language. I must learn it sometimes :)
<psykose>
decisions based on prejudices are usually not very good
* tophevich[m]
can't get "happily make default" and "a lightweight installer to have jre as a dependency" to compute
<sven>
the "lightweight" installer needs to download 1gb or so of data anyway. it truly doesn't matter.
<j_ey>
sven: RIRR
<j_ey>
err RIIR
<tophevich[m]>
I thought java is quite "borked" on macOS
nobodynada has joined #asahi
<landscape15[m]>
sven: As i saw, the installer extract the entire IPSW, but it doesn't take a long time. Only my connection is quite slow.
<sven>
uh
<sven>
it doesn't even download the entire IPSW
Nspace has joined #asahi
<kov>
is java not borked anywhere? especially for GUI? hehe
<landscape15[m]>
I personally like Java GUI. I don't find it so terrible...
<landscape15[m]>
Moreover it works very well with OOP
<kov>
I'll say this though: starting a new project in C in 2021 should be considered a crime against humanity, especially now that we have Rust
<kov>
it doesn't make sense to choose something that lets you shoot your foot so easily at this point
<landscape15[m]>
kov: So why XNU, the Linux kernel and other OS parts are built in C? I thin it's still the more efficient for low level programming.
<j_ey>
those werent started in 2021
<kov>
landscape15[m], historical reasons, Rust didn't exist at that time
<sven>
oh dear
<kov>
on a slightly less off topic note, is there a recommended repo/branch for testing with an M1 Air?
<sven>
i think alyssa has a branch somewhere with almost all of our not-yet-upstreamed drivers
<j_ey>
but that doesnt contain keyboard for the air
<kov>
I think I looked at alyssa's branch but it lacked the Air dtb and keyboard, yeah
<j_ey>
but those are easy to cherry-pick
<landscape15[m]>
j_ey: Yeah but it would be a pain to make a full transition, wouln't it...
<j_ey>
landscape15[m]: yes, but you started asking about an installer..
<_alice>
I think for a fancy GUI installer on macOS of all platforms, wouldn't Obj-C + Cocoa, or Swift + SwiftUI make the most sense?
<_alice>
perhaps with PyObjC bindings for the existing code
<kov>
I was looking for something more pret-a-manger for a quick validation of my setup, then I can do that cherry-picking
<j_ey>
kov: well if you want keyboard, my branch has that, but nothing else.. lol
<landscape15[m]>
j_ey: Yeah i'm off topic. I mean for low level programming it's still quite solid.
<_alice>
I think it'd be pretty neat to have a fancy install flow that pre-stages the distribution installer for the next reboot after step2.sh, kinda like how there were Windows GUI installers for Linux back in the day
<kov>
j_ey, haha well, I guess that one it is then, then I can try to merge with alyssa's
<j_ey>
landscape15[m]: only because of history
<_alice>
(but I think for now, the python installer is fine, given that Python is already available in the base system)
<j_ey>
kov: it'll be easier to use alyssa's and merge the keyboard into that
<sven>
_alice: yup, having a fancy installer with a nice UI would be a lot of fun :)
<kov>
j_ey, cool, thank you, I'll give this a go over the weekend more likely, will report back if I get to a many-hacks + Air keyboard branch
<j_ey>
kov: many-hacks or whatever her branch is has the pinctrl code, so you only need to cherry-pick a few from the very start of my branch
<alyssa>
j_ey: I don't mind SPI patches in my downstream, I just can't test them
<alyssa>
I also don't know if the DCP driver is working on the MacBooks yet for the same reason.
<j_ey>
those corellium ones seem pretty stable in terms of 'no-one is working on them', and then hopefully it can be replaced later on with a cleaner driver
<alyssa>
Let me know what to cherrypick and I'll take them
<alyssa>
or is it just unmodified corellium spi? i can grab those I guess.