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
amw_ is now known as amw
DragoonAethis has quit [Quit: hej-hej!]
DragoonAethis has joined #asahi
Gues__________________________ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
eric_engestrom has quit [Ping timeout: 480 seconds]
steev_ has joined #asahi
steev has quit [Ping timeout: 480 seconds]
jkkm has quit [Ping timeout: 480 seconds]
jkkm has joined #asahi
eichin has quit [Ping timeout: 480 seconds]
eric_engestrom has joined #asahi
eichin has joined #asahi
yuyichao has joined #asahi
malvo has quit [Read error: Connection reset by peer]
malvo has joined #asahi
steev_ has quit []
steev has joined #asahi
phiologe has joined #asahi
Gues__________________________ has joined #asahi
PhilippvK has quit [Ping timeout: 480 seconds]
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
<chadmed>
https://browser.geekbench.com/v5/cpu/10476727 im sure most have probably seen this already but this puts the M1 Max at approx. a stock ryzen 5800x in terms of raw performance. quite impressive, imo
<jannau>
pro/max doesn't seem to have an effect larger than the noise in those results
crabbedhaloablut has quit [Ping timeout: 480 seconds]
crabbedhaloablut has joined #asahi
nobodynada has quit [Quit: Lost terminal]
bingoChecker has joined #asahi
<tophevich[m]>
jannau: afaik for cpu benchmarks the only thing that could make a difference is the memory bandwidth difference between the 32 pro and the 64 max, where the benchmark would realy make use of the extra bandwidth. when talking about the rest of the soc you'd need specific benchmarks as well like one for ProRes, graphics ... and so on
<_jannau_>
yes, only memory badnwidth and probably larger system level caches could make a difference but either they don't or the difference is too small within geekbench
X-Scale` has joined #asahi
X-Scale has quit [Ping timeout: 480 seconds]
<mini>
that's ridiculous really... 5800X level performance in a third or less of the power? mental
<tophevich[m]>
yea, I'd say the have a bit of a thermal headroom for the desktop pro models :D
<tophevich[m]>
s/the/they
<mini>
I actually happen to have a 5800X, so I'l enjoy comparing the two when my new shiny arrives :)
<phire>
I have the 3900x, which is about the same multithreadded as the 5800x
<ar>
doesn't GB play into the fixed-function parts of their soc?
<tophevich[m]>
But I'm currious what they'll do about the die/soc size, and the scaling of it. If they keep all the gpu bits in there (which they will want to scale up even further) and scale the cpu cores + caches at the same time ...
<mini>
well, by all accounts the M1 Max die is absolutely massive, I'm just curious as to how they do the desktop ones
frytaped has quit [Quit: went bye bye]
frytaped has joined #asahi
<tophevich[m]>
that's what I'm saying :D
pwg has quit [Ping timeout: 480 seconds]
<chadmed>
i wouldnt be surprised at all if they are haemorrhaging money on the chips, but it doesnt matter if theyre turning a profit on the system as a whole
<chadmed>
theyll get to MCMs eventually too, and probably next gen just have two dies that they bin for each product segment. it cannot be cheap supplying 3 dies with so few bins on each
pwg has joined #asahi
maennich has quit [Read error: Connection reset by peer]
maennich has joined #asahi
chadmed has quit [Remote host closed the connection]
chadmed has joined #asahi
<marcan>
2 Max dies is supposedly the story, before the next actual chip gen
<marcan>
I wonder how the GPUs work in that, do they actually schedule work cross-die or is it all software-managed?
<chadmed>
if theres no hidden hardware for that kind of thing on die right now, id imagine theyre probably just hooked together with AMBA or some other fabric and its all handled in software
<ar>
i would really want to see the m1max in a mini.
<chadmed>
im hoping before christmas to save me the hassle of getting a maxxed-out mbp, but its probably unlikely :(
<kettenis>
marcan: any chance for you (or someone else on here) to dump the ADT in .adt.txt format like you did for the earlier ones?
<marcan>
suer
<marcan>
*sure
<kettenis>
need to figure out how to do that myself at some point, but I'm really curious to see what changed and I don't really want to download that full ipsw right now
<marcan>
ha, they broke my ADT parser
<kettenis>
oops
<marcan>
specifically on the new machines
<marcan>
let's see what's going on ..
<chadmed>
youve already got one of the new machines? theyre not shipping for at least another monthe here lol
<marcan>
no, I downloaded the IPSW
<kettenis>
the "template" ADT is part of the firmware/OS
<kettenis>
so it lacks the details filled in by iBoot, but it gives a good idea how the hardware changed
<sven>
hmm.. dart is dart,t6000 now.
<sven>
and it also comes with "aic,2"
<marcan>
Exception parsing /device-tree/arm-io/mcc.dramcfg-data value 0000ffff:
<marcan>
pmgr.devices changed, we'll have to figure out what's up with that
<marcan>
2 p-clusters as I expected
<marcan>
so I was right in generalizing everything to multiple cluster configs
<marcan>
reg = [Container:
<marcan>
addr = 0x000000019B200000
<marcan>
crap, the uart moved
<marcan>
I was hoping not to have to deal with that...
<marcan>
now what... I guess I comment out the early bring-up debug in m1n1 and make the real uart code just parse the ADT
<marcan>
the dramcfg thing definitely changed; I wonder what they do now and how it interacts with the two p-clusters
<marcan>
they also have PLL_GFX01 and PLL_GFX23 now, which looks like the GPU is segmented to some extent
<marcan>
still just a single sgx node though, so I'm guessing at least in single-chip cases that's all still magically hidden
<marcan>
gpu-fast-die0-integral-gain = 1140457472
<marcan>
that suggests the gfx asc will also take care of multidie
maor26 has joined #asahi
<phire>
so it it actually 4 seperate GPUs on the Max?
<phire>
(in 2 clock domains)
<marcan>
we don't know, I guess that depends on what you call a "GPU"
<marcan>
these GPUs are tiled, and were already split into cores anyway, so there's always been some magic dispatch
<marcan>
I guess there's just more of that
<phire>
I guess it gets very philosophical
<povik>
what's that, sn012776 driving the speakers on macbook pro
<dottedmag>
Are there several command streams per GPU (1 per core?) in M1 already, or is doing magical dispatch by parsing a single command stream?
<povik>
look what's on spi2
<povik>
compatible = [biosensor,mesa]
<povik>
anyone knows what's that?
<chadmed>
probably touch id?
<sven>
don't think so
<sven>
that's entirely handled in the SEP
<chadmed>
oh yeah of course thats all separate isnt it
<sven>
yeah, you just have a ipc protocol and ask the SEP to authenticate or decrypt something
<sven>
and it does its magic and give you back the result
<sven>
*gives
<marcan>
mesa is touch id
<sven>
huh. but why is it exposed to the AP then?
<marcan>
who says the AP doesn't proxy it?
<marcan>
remember it needs to proxy bluetooth keyboard touch ID too
<sven>
hrm, true.
<marcan>
it's all encrypted anyway
<sven>
right. and i wouldn't have seen it on the mac mini when i was tracing the SEP because it obviously doesn't have touch id
<marcan>
yup
<marcan>
it's been like this on the M1s too
<sven>
yeah, i guess i just assumed it was all hidden inside the SEP because i never saw any IPC messages
<sven>
... because that mini just doesn't have it ofc, but i forgot that part
<kettenis>
marcan: thanks
latosca[m] has joined #asahi
X-Scale has joined #asahi
X-Scale` has quit [Ping timeout: 480 seconds]
yorgos has joined #asahi
yorgos_ has joined #asahi
yorgos has quit []
yorgos_ has quit []
<bgb_>
marcan: I'm confused about the iodev thing. if i boot linux with run_guest.py, USB1(ttyACM1) is used for vuart redirection, USB0 is used for uartproxy(default M1N1DEVICE=ttyACM0), is that right?
<kettenis>
that's what I get with OpenBSD running on a single e-core
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi
<marcan>
bgb_: yes
<bgb_>
marcan: I see "Initializing hypervisor over iodev IODEV.USB1", and for HV, self.iodev = self.p.iodev_whoami() = uartproxy_iodev(uartproxy.c).
<bgb_>
I mean uartproxy_iodev is the device used by uartproxy, I really got confused.
Gues__________________________ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<brentr123[m]>
Is this on the new Macs?
<_jannau_>
bgb_: the iodev numbers on the m1 depend on the port used for uartproxy. that has nothing to do with the ttyACM devices on the connected linux host
Gues__________________________ has joined #asahi
yuyichao has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi
aleasto has joined #asahi
Gues__________________________ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nobodynada has joined #asahi
<marcan>
bgb_: USBn is ttyACM0, USBn_SEC is ttyACM1 (normally)
<marcan>
n just depends on the port
bakedpotatoez[m] has joined #asahi
bingoChecker has quit [Quit: Leaving]
<bakedpotatoez[m]>
Hey I'm new here. I just heard of Asahi and I was wondering if it's ready for use or if it's still in development?
<marcan>
still in development; adventurous developers are free to try things though
tertu has quit [Quit: so long...]
tertu has joined #asahi
<mort_>
I should probably blow a whole bunch of money on the new macs shouldn't I
gabuscus has joined #asahi
gabuscus_ has quit [Ping timeout: 480 seconds]
gabuscus_ has joined #asahi
gabuscus has quit [Ping timeout: 480 seconds]
rohin has joined #asahi
nobodynada has quit [Ping timeout: 480 seconds]
nobodynada has joined #asahi
<bakedpotatoez[m]>
<marcan> "still in development; adventurou..." <- Aw okay. Thanks anyways!
<bakedpotatoez[m]>
There isn't an ETA is there?
nobodynada has quit [Ping timeout: 480 seconds]
<marcan>
there never is :)
<i509vcb[m]>
<bakedpotatoez[m]> "There isn't an ETA is there?" <- What's an ETA lol
<i509vcb[m]>
(anyways welcome to open source)
<jn>
bakedpotatoez[m]: there might be some estimates sometimes
<jn>
but the concept raises in important question without a clear answer: when are we done?
nobodynada has joined #asahi
<jn>
some stuff works already, and you can arguably run a functional mac mini desktop with asahilinux now (after finding the right kernel branches and spending some time on installing)
<j_ey>
Glanzmann: "1.65 times faster than Linux" should be macOS, not Linux?
<Glanzmann>
yes.
<Glanzmann>
j_ey: Corrected.
<Glanzmann>
kettenis: My models (macbook air and mini) have 500 GB NVMe.
<tertu>
the modern minis are passively cooled right, maybe they'll just go to fans like on the G4 mini
<Glanzmann>
tertu: Nope, they have a fan but it rarely engages.
<Glanzmann>
For me it never turned on so far.
<Glanzmann>
But if you watch a 4k video on cpu or run qemu it will.
riker77 has joined #asahi
<mini>
mine's practically always on, just near silent
<Glanzmann>
mini: I normally use an intel nuc as workstation which is really noisy. If the nuc is off, I don't hear anything. For me the mini appears to be silent.
<mini>
Glanzmann: yeah, it's not even close. I have a nuc8i5beh here too and that is very very noisy
<mini>
the mini is essentially silent
<Glanzmann>
mini: I have the very same model (NUC8i5BEH): [ 0.000000] DMI: Intel(R) Client Systems NUC8i5INH/NUC8i5INB, BIOS INWHL357.0043.2021.0817.1957 08/17/2021
Gues__________________________ has joined #asahi
<Glanzmann>
mini: Did you tune the fan curves for the nuc? I didn't and it is noisy as hell.
kenjigashu has quit []
aleasto has quit [Remote host closed the connection]
aleasto has joined #asahi
aleasto has quit [Remote host closed the connection]
aleasto has joined #asahi
<mini>
Glanzmann: no, I haven't. to be honest I use it as little as I can get away with, it's just too loud
<mini>
if the m1 mac mini had existed when I'd bought it... I'd never have bought it :p
aleasto has quit [Remote host closed the connection]
nobodynada has quit [Ping timeout: 480 seconds]
aleasto has joined #asahi
alexstore06 has joined #asahi
alexstore06 has quit [Quit: Leaving...]
alexstore06 has joined #asahi
Glanzmann has quit [Quit: EOF]
yuyichao_ has joined #asahi
yuyichao has quit [Ping timeout: 480 seconds]
nobodynada has joined #asahi
jeffmiw has joined #asahi
nskl has joined #asahi
nsklaus_ has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi
yuyichao_ has quit [Ping timeout: 480 seconds]
jacoxon has quit []
Gues__________________________ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<kettenis>
Glanzmann: this is a 1TB machine
<citizen1[m]>
how linux will work with a macbook with a notch?
<j_ey>
citizen1[m]: just like macos will probably
<j_ey>
the first attempt will be to probably just try make the screen only go up to the bottom of the notch
<mort_>
that sounds like a reasonable compatibility mode
<mort_>
at the very least
<mort_>
it would be cool to let application content only use the part below the notch, but then put some permanent status bar type thing in the space with the notch in such a way that it's not even covered by true fullscreen apps
<citizen1[m]>
this is not exactly asahi question but m1 . So m1 is powerful enough thats its actually just as powerful as discreet gpus from nvidia and amd?
<mort_>
apple's benchmarks showed that the m1 max is very nearly as fast as the mobile edition of the RTX 3080
<citizen1[m]>
mort_: maybe a widget to make virtual bezel on the sides of the notch to hide it
<citizen1[m]>
mort_: mind boggling , rtx has its own fans
<citizen1[m]>
that risc is some black magic
<mort_>
there's a big difference between the desktop RTX 3080 and the mobile RTX 3080
<mort_>
the memory is insane though, DDR4 has a throughput of 25.6 GiB/s, the new M1s have 200 and 400 GiB/s
<citizen1[m]>
my understanding that ddr4 is ram memory, how this affects speed of computation?
<mort_>
depends a lot on the particulars of what you're doing
<mort_>
there are a bunch of levels of cache, typically 3 (l1, l2, l3), where l1 is basically instant to access but small, l2 is a bit slower to access but bigger, l3 is slower still to access but even bigger, and then there's the RAM which is huge but very slow to access
<mort_>
if your entire dataset fits within the CPU's cache, then it doesn't have to touch RAM and memory bandwidth doesn't matter at all
<mort_>
if your dataset doesn't fit within the cache, you have to read it from RAM, at which point the speed of accessing the memory becomes a potential issue
<mort_>
if you have to read from RAM, but you're doing random access to RAM, throughput doesn't matter a lot, latency is much more important
<mort_>
but if you have to read from RAM, and you're doing sequential (or otherwise predictable) access to RAM, *then* throughput becomes very important
<mort_>
example: if you're applying some effect to an image, you'll be iterating through every pixel in the image; you'll probably be doing that with all 10 cores at the same time, going over different sections; all 10 cores will be doing sequential access, and if the amount of work per pixel is relatively small, you may end up being limited by RAM
<mort_>
bandwidth
aleasto has quit [Remote host closed the connection]
<mort_>
sorry for the wall of text, but how RAM affects the speed of computation doesn't have a very simple explanation
<citizen1[m]>
thanks for explaining
<mort_>
np
alexstore06 has quit [Ping timeout: 480 seconds]
Gue___________________________ has joined #asahi
Gue___________________________ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]