04:13 <chadmed> incredible that its only taken a couple of weeks to get audio on these macs in a state roughly equivalent to their Intel counterparts, which has taken almost a decade and still doesnt work properly :P

05:28 <marcan> awesome! :D

05:28 <marcan> chadmed: this stuff isn't hard... if you *have* people working on it

05:29 <marcan> I think a lot of people don't realize that Mac support on Linux has largely been a haphazard thing until now, but this time we have a whole bunch of people working together

05:30 <marcan> (and funding, which means there is no excuse for progress to stop)

05:30 <marcan> and yeah, audio doesn't work on my intel iMac :>

05:30 <marcan> I don't care because I use an external interface anyway

05:31 <marcan> maybe if a few years down the line I actually find myself without Asahi stuff to do for a week I'll take a look at it :p

06:24 <chadmed> marcan: yeah i just think its funny that the platform has received more love in 9 months than it has had for the past 10+ years. i use an external dac at my main workstation regardless but i dont have a dock for my macbook so its a bit messy and un-ergonomic to have a bunch of USB cables sticking out of a hub

06:25 <marcan> heh, yeah

06:25 <marcan> it helps that apple actually put out something unique though

06:25 <marcan> it's a lot harder to get people interested in "intel, but shiny aluminum"

06:25 <sven> having that hypervisor also helps a lot. reverse engineering kexts is terribly annoying

06:25 <marcan> :>

06:25 <marcan> glad that was a month well spent

06:26 <sven> even finding those dumb %s.debug=0xff arguments isn't fun because there's like two or three layers of vtables involved

06:26 <chadmed> yeah the novelty of an actually fast arm workstation probably attracted most of the interest at this point. if the performance and efficiency of the A15 is anything to go by it looks like that novelty will be sustained for at least a few generations of hardware

06:26 <marcan> yeah

06:26 <marcan> sven: you do have a script to fix the stupid PAC-ished vtables, right?

06:27 <marcan> (I have one on ghidra)

06:27 <marcan> but even with that following them is annoying

06:27 <marcan> chadmed: I heard that power management is even more amazing on that one

06:27 <marcan> and the thing is, anything that is good by phone standards is killer by laptop standards

06:27 <sven> mine requires me to manually specify the vtable once (for which i use the hv), but yeah

06:28 <marcan> e.g. if you can have a phone survive idle for a day, with laptop sized batteries that's a week

06:28 <marcan> ah, mine does it automagically

06:28 <sven> i was too lazy to do that :D

06:28 <marcan> I just took someone else's script :p

06:28 <sven> :>

06:28 <chadmed> a friend of mine quite simply does not believe it is possible to have 30 hours of video streaming out of a phone battery. they flatly deny it. maybe i buy an iphone 13 and set up a live stream where i just have it play back videos until the battery dies to prove a point :P

06:29 <marcan> ahahaha

06:29 <marcan> it helps that apple are optimizing the crap out of that use case

06:29 <sven> lol

06:29 <marcan> it's basically the CPU kicking hardware engines that do everything

06:29 <marcan> the GPU is literally off while streaming video on these devices

06:29 <marcan> (e.g. on safari on macos)

06:29 <marcan> it just goes straight to a DCP plane

06:29 <marcan> might be a bit tricky since you need special bypass paths

06:30 <marcan> but it would be nice if e.g. firefox grew support for this on M1s on Linux

06:33 <marcan> chadmed: tbh I'd been waiting for a nice ARM box for over a decade now

06:33 <marcan> I just was not expecting Apple to be the one to do it back then, but here we are

06:35 <chadmed> pretty considerate of them to release these machines right around when i was starting to grow tired of x86/amd64 too

06:39 <marcan> pretty considerate of them to release these machines when I'd gotten tired of jailbreak platforms but I still wanted to spend time porting linux to new hardware :)

06:40 <marcan> unrelated: looking at the pstates again I have a theory about why 3.2GHz is single core

06:40 <marcan> 3.0 GHz+ is at the same voltage

06:40 <marcan> that doesn't make any sense for actual CPU core voltage, you have to increase the voltage to go higher

06:41 <marcan> so instead I bet the story is that it's the voltage at the package/cluster level, but then there is IR drop to the actual core

06:41 <marcan> and that IR drop is lower if only one core is active

06:41 <marcan> so effectively by shutting down cores they boost the voltage, without increasing the actual input

06:41 <marcan> but that really does need the other cores to be pretty much dead to get enough of a boost to safely increase the clock

06:42 <marcan> of course then the question becomes why don't they just boost the voltage higher anyway to be able to fire off more cores, but maybe they thought at that point the power curve would get too out of control?

06:43 <marcan> so effectively one way of thinking about this is that this is a 3.0GHz 4-core CPU that "just happens" to be able to boost to 3.2GHz single core for free, at the same settings, on a single core at a time

06:43 <marcan> just due to physics

06:47 <chadmed> is the reduction in vdroop really significant enough that just setting that "new" voltage on all cores would tank the efficiency? it could also just be a safe level that all chips validate so that the only binning they have to do is for defective AGX cores

06:50 <marcan> yeah, it could be a safety thing, unclear