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-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
jabashque has quit [Quit: Connection closed for inactivity]
zkrx has quit [Ping timeout: 240 seconds]
inglor has joined #asahi
zkrx has joined #asahi
phiologe has quit [Ping timeout: 245 seconds]
phiologe has joined #asahi
odmir has joined #asahi
jeffmiw has joined #asahi
jeffmiw has quit [Ping timeout: 265 seconds]
marvin24 has quit [Ping timeout: 245 seconds]
marvin24 has joined #asahi
odmir has quit [Ping timeout: 240 seconds]
odmir has joined #asahi
odmir has quit [Ping timeout: 240 seconds]
VinDuv has joined #asahi
m0drobert is now known as modrobert
jabashque has joined #asahi
VinDuv has quit [Quit: Leaving.]
leah2 has joined #asahi
herbas has joined #asahi
ephe_meral1 has joined #asahi
odmir has joined #asahi
odmir has quit [Ping timeout: 240 seconds]
herbas has quit [Quit: herbas]
jeffmiw has joined #asahi
jeffmiw has quit [Ping timeout: 252 seconds]
bgb has joined #asahi
Serentty has quit [Quit: Idle for 30+ days]
<bgb>
It seems that big cores run at 600M Hz, is it possible to scale up to 3G Hz at m1n1?
Bublik has quit [Ping timeout: 265 seconds]
zkrx has quit [Ping timeout: 252 seconds]
Bublik has joined #asahi
zkrx has joined #asahi
raster has joined #asahi
maknho_ has joined #asahi
<marcan>
bgb: cpufreq management will be done in linux, but in a pinch I'm sure we can add some minimal support to m1n1
maknho has quit [Ping timeout: 265 seconds]
<bgb>
marcan: just reading Corellium's cpufreq support, not sure if the registers come from open-sourced xnu.
<marcan>
bgb: if they do I'm happy to use it, if they don't, well, I'm sure I'll have information on them soon from mmiotrace
<marcan>
anything I can easily work out with mmiotrace, I'd much rather do that way than use the corellium code as a reference
<bgb>
another question is, cpu frequency usually related to voltage and ddr frequency, I can see voltage related config in their code, but there seems no ddr freqency.
<marcan>
they should be independent, but yeah there should be some control for it
<marcan>
however, remember there is a power manager sub-cpu that might take care of a lot of this for us
<marcan>
so it's possibly that is implicitly managed or something like that
<bgb>
do wish that
<marcan>
seems PMP indeed manages DRAM bandwidth and presumably clocks
<marcan>
judging by strings
<marcan>
DRAM power greater than threshold power = %u mw
<marcan>
DRAM energy greater than threshold energy = %u nj
<marcan>
RT BW Req.
<marcan>
Clock Req.
<marcan>
should be interesting to see what the interface is, if this is implicit or if we actually need to issue commands to it to tell it e.g. what the display pipe isochronous bandwidth requirement is
<marcan>
display is managed by another engine though, so they might just communicate among themselves for that
<marcan>
strings on DCP suggests there is in fact some doorbell or interface to take care of this exchange, presumably behind the scenes
<marcan>
yup, DCP definitely talks to PMP
<marcan>
yay, less things to care about
<bgb>
sorry, what is DCP?
<marcan>
display controller processor (guess)
<marcan>
deals with a lot of the details of display pipe setup and such
<bgb>
make sense
<marcan>
I'm very curious as to what the OS level interface to it is
<marcan>
might be pretty high level, which would make our DRM/KMS driver for this largely a shim in that case
<marcan>
I'm very much looking forward to not having to deal with DisplayPort training, hopefully :-)
<bgb>
seems currently big core's freq is at low frequency, right?
<_jannau_>
yes, the efficiency cores are clocked around 2GHz (iirc) and faster than the performance cores at bootup
<marcan>
probably upclocked by iBoot to speed up boot
<bgb>
yeah, i also notice that.
<bgb>
wonder why it doesn't speed up big core to 3G and boot faster
<marcan>
because the little core is core 0, and probably because big cores are more likely to need chicken bits to not explode
<marcan>
(they do have more of them)
<_jannau_>
I guess the efficciency cores can safely run at full power without down clocking/fan activation but the performance cores can not
<marcan>
I wouldn't expect boot to be significantly CPU-limited anyway; other than uncompressing xnu (which I don't think takes that long), it's probably largely limited by hardware bring-up delays and such
<marcan>
certainly on this kind of machine
<marcan>
smaller systems are another story
Bublik_ has joined #asahi
Bublik has quit [Ping timeout: 240 seconds]
hsaias has joined #asahi
rjeffman has joined #asahi
maknho_ has quit [Ping timeout: 260 seconds]
maknho_ has joined #asahi
Ariadne has joined #asahi
<bgb>
as for performance, under the condition that PMP handles the overall frequecy scaling, do you think performance like IPC(inst per cycle) is proportional to frequency?
<marcan>
bgb: IPC is fixed by definition for any given microarchitecture and benchmark, modulo memory stalls and such
<sorear>
going from 600MHz to 3000MHz you (ideally) run 5x as many instructions but you also have 5x as many cycles, so it cancels out in the ratio
<jix>
marcan: some intel CPUs do change IPC for some AVX code depending on freq and/or voltage: https://travisdowns.github.io/blog/2020/01/17/avxfreq1.html but that's pretty much the exception and I would be very surprised if apple would be doing anything like that
<jn__>
bgb: to put it slightly differently: instructions per second is roughly proportional to frequency; the ratio between the two is instructions per cycle
<marcan>
jix: okay yeah intel are weird
jeffmiw has joined #asahi
jabashque has quit [Quit: Connection closed for inactivity]
jeffmiw has quit [Ping timeout: 246 seconds]
<bgb>
marcan: I think you mean max IPC is fixed inside core. But if a program is memory sensitive, it becomes complicated. assume ddr latency is roughly fixed at some config, a memory cost program(I mean cache miss frequently) runs with less cycles at lower frequency, inst is fixed for specific program, so IPC increases at lower freq