marcan changed the topic of #asahi-gpu to: Asahi Linux: porting Linux to Apple Silicon macs | GPU / 3D graphics stack black-box RE and development (NO binary reversing) | Keep things on topic | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-gpu
JusticeEX has joined #asahi-gpu
phiologe has quit [Ping timeout: 244 seconds]
phiologe has joined #asahi-gpu
Baughn has quit [Ping timeout: 260 seconds]
Baughn has joined #asahi-gpu
odmir has quit [Remote host closed the connection]
linuxgemini has quit [Read error: Connection reset by peer]
Necrosporus is now known as Guest13098
Guest13098 has quit [Killed (weber.freenode.net (Nickname regained by services))]
<jix_>
morelightning[m]: FYI, if you write multi-line messages in matrix, they get bridged to IRC as a https link to a .txt file, so if you mention someone in them they might not see that
<morelightning[m]>
oh, is there a better software I should use? (It's been over a decade since I've used this stuff)
<jix_>
using matrix is fine IMO, it's just good to be aware of how the bridge handles multi line messages... it's suitable for posting code or logs etc, but not so much for conversations
jix_ is now known as jix
<jix>
I'm using both matrix and irc, but for irc channels I usually connect directly, but that requires a persistent connection if you want to see all messages in channels that are not publicly logged (this one is though, see topic)... tastes in preferred clients vary widely and discussions about that usually lead to long off-topic discussions so I'd rather not go there
<morelightning[m]>
Is there any insight yet into bypassing the window compositor or how that connects? My initial assumption would be that metal's "present drawable" does a composite with a basic shader, and then it just passes the frame buffer along at some point... maybe thats around CoreDisplay?
<bloom>
No, I very intentionally have prioritized off-screen rendering since CoreGraphics would be a massive r/e effort with 0 payoff for Linux.
<morelightning[m]>
Well, what I mean is, on linux, we'll have to route the frame buffer to the display somehow - is that part of the hardware addressing identified already?
opticron has quit [Ping timeout: 240 seconds]
TheJollyRoger has quit [Ping timeout: 268 seconds]
opticron has joined #asahi-gpu
TheJollyRoger has joined #asahi-gpu
<morelightning[m]>
My assumption, was that if we haven't identified those yet, that I might find them defined inside CoreDisplay or close to it.
<bloom>
That's not the GPU, that's the display controller.
<bloom>
marcan: ^
<sven>
the frame buffer is pre-configured by iboot for us as some buffer in main memory. we'll eventually have to figure out how the display controller works, but as long as we can render to some buffer from the gpu it'll work for now
<sven>
and ideally we'll figure out the display controller by observing MMIO reads/writes once marcan implements a mini-hypervisor in m1n1
<marcan>
display controllers are boring, it's just a pile of mode parameters and stuff like that
<marcan>
observe mmio writes, tweak things, figure out what they mean
<marcan>
it's a bunch of work to write the driver but all the annoying details are going to be around things like DisplayPort link training, HDMI InfoFrames, and all that "fun" stuff
<marcan>
it should be pretty much completely divorced from the GPU, and since Linux has a very mature DRM/KMS framework for handling all that stuff, which is going to be very different from how macOS does things (most likely), there isn't really any reason to try to figure out how macOS does things there
<chrisf>
marcan: do we expect the apple display controller to be small like desktop, or a mobile-style behemoth?
<marcan>
define mobile-style behemoth?
<chrisf>
marcan: on socs designed for android the display controllers are often enormous -- tons of planes, etc
<marcan>
oh, you mean compositing
<marcan>
good question
<marcan>
I don't really know; my gut feeling is Apple would use the GPU for that, but I guess we'll find out
<marcan>
they definitely do basic scaling at least, since that's how their entire macOS DPI scaling is implemented
<marcan>
(AIUI they only do a couple fixed DPI values, then scale for everything else)
<marcan>
oh yeah, one thing that's going to be fun is memory bandwidth calculation stuff
<marcan>
not looking forward to *that* one...
<morelightning[m]>
The m1 mac window compositor is showing up as a Metal vertex/fragment shader in Instruments, just like the iPad. So I was supposing that all the information we need is just sitting defined inside the window server process.
<morelightning[m]>
On the iPad, I vaguely remember something new in the last few years about needing to control the contrast range of the display - so I was assuming we'd run into that on the mac too.
<marcan>
I don't think we should need *anything* about the compositor
<marcan>
it's just more 3D
<marcan>
OTOH, I just did a bit of `strings` recon on their display controller driver
<marcan>
chrisf: looks like it's huge, but not because of compositing stuff... there's a whole mailbox protocol involved apparently, and some rather fancy stuff
<marcan>
I get the feeling we can *probably* get away without a lot of it, since it's probably intended for mobile panels where there are a million variants, with weirdo OLED subpixel layouts and stuff like that
<marcan>
the only OLED panel we have to deal with is the Touch Bar, but that can wait a bit
<marcan>
(going to be funny extending x11/wayland screens into that; putting the Plasma taskbar on the Touch Bar, anyone? :p)
<marcan>
it might support... 3 layers?
<marcan>
what worries me is I think I see some firmware in here... I hope this is legacy
<marcan>
there's a DCP that iBoot2 loads for us at least
<marcan>
looks like DCP is probably the DP/HDMI encoder block, so I guess most of that is handled by firmware with some kind of mailbox to talk to it
<marcan>
there's a whole 7MB of firmware for that, which is insane. I wonder what's in here.
<marcan>
at least that probably means it does link training for us
<marcan>
the DCP firmware is definitely also working with things at the framebuffer level, at least to some extent, so maybe in the end it'll boil down to a big mailbox thing?
<modwizcode>
Would the plan be to extract that or were you saying that iBoot loads it for us?
<marcan>
oh well, either way this is going to be fun
<marcan>
modwizcode: for everything iBoot2 loads for us, they're just files next to iBoot2; all that stuff will have to be copied from the recovery partition for our "clean" installer
<modwizcode>
? not exactly clear what you mean there.
<modwizcode>
It sounds like you're saying that iboot loads it but also that it doesn't?
<marcan>
it does, but iBoot2 is part of the "OS" install, so we need to put it there if we're doing a from-scratch install
<marcan>
along with all the firmware blobs it loads
<modwizcode>
ohhhh
<modwizcode>
I didn't realize where iBoot2 resides
<daniels>
chrisf: if I had to guess, more complex than desktop, less complex than Qualcomm
<daniels>
given their battery life figures, I have a hard time believing that they're using the GPU to composite every frame (at least when not doing fullscreen desktop)
<modwizcode>
I'm surprised that more of that isn't done honestly
<marcan>
they used a tiling architecture and the framebuffer is also tiled, so it would make sense for them to do a dirty tiles thing for updates, instead of compositing the entire frame
odmir has joined #asahi-gpu
<marcan>
but so far I've seen mentions of 3 layers in here, so I don't think they delegate much compositing to the display controller
<modwizcode>
even the OLPC people implemented a basic display controller level redraw handling thing, it's hardly cutting edge.
<modwizcode>
for compositing tiles would be plenty
<sven>
oh... that mailbox probably explains why the framebuffer only sometimes broke when i wrote different values to the area called "piodma" that is mapped after the framebuffer
<daniels>
marcan: 3 is plenty: one for system UI, one for browser chrome, one for Netflix content
<daniels>
realistically you don't need too many more if you do the HWC thing of using the GPU to flatten your static-ish content to a single buffer, then using the display controller for the more dynamic content
<marcan>
makes sense
<bloom>
^ seconding what daniels said, given how optimized for power efficiency the rest of the apple soc's are, and how cheap an extra overlay plane is, this would be a really bizarre place to skimp on gates
<daniels>
(not surprising that Apple actually did it properly, but it is sadly uncommon for GPU render targets and display controller fetch to share tiling formats ...)
<daniels>
but yeah, enabling things like PSR is a seriously frustrating long-tail effort
<bloom>
M1 has full support for tiled compressed framebuffers, documented absolutely nowhere
<bloom>
Gotta hand it to Apple, even Arm and Qualcomm brag about AFBC/UBWC despite keeping the internals proprietary.
<bloom>
Apple has managed to excise every mention of a compression scheme from public docs/source.
<modwizcode>
ahh heh
<bloom>
Admittedly I don't nknow what the display controller ingests, I just saw this in flight from app<-->compositor
<bloom>
but again Apple is far too competent to not have their display controller ingest their compression scheme as well
<modwizcode>
I mean if you're making both you might as well reuse your hdl c;
<marcan>
bloom: there is plenty of mention of tiling/compression in these blobs
<marcan>
so yes
<bloom>
Better question is if the cameras support the compression scheme too
<bloom>
(at least on the iPhones with fancy 4k@60..)
<marcan>
ha :)
<marcan>
good question
<modwizcode>
don't they use off the shelf camera parts tho?
<marcan>
there's a separate image processor, presumably for that stuff
<bloom>
I know Arm has camera stuff feeding into AFBC but I don't know if it (or anything like it) ever shipped.
<bloom>
Likewise, can the video decoder recompress to the native format on the fly?
<bloom>
(IIRC Arm has this too, also not shipping afaik)
<bloom>
4k on mobile is rather painful withot compression, so
<daniels>
Arm never got their media-codec IP in any shipping SoC TTBOMK, but they will license AFBC to you if you want to do that
<daniels>
(I've also not seen it in the wild)
<bloom>
Alas
<daniels>
but given that your phone doesn't have a 4K display, rather than compressing 4K output, the secret is to just ... not have it
<daniels>
keep an internal camera -> ISP -> codec pipeline which spits out a downscaled YUV/RGB frame for display, and then the codec goes straight to H.264/HEVC/whatever, ideally without touching sysmem
<daniels>
(yes it's a lot of out-of-band storage, but cheaper in power than keeping DDR lit up full)
<marcan>
I actually can't find the video decoder firmware, and now I wonder if it's in the SEP. because DRM.
<daniels>
marcan: presumably it's a stateless impl -> very possibly no firmware?
<daniels>
just a big old userspace blob
<marcan>
could be
<daniels>
any idea if it's in-house or licensed?
<marcan>
I should start listing these engines on a wiki page somewhere. e.g. AOP is "hey siri" and other sensor stuff, PMP is power, ISP is the camera stuff, DCP is the displayport/display stuff, AVE is the encoder, ANE is neural engine
<modwizcode>
There's already a glossary page, want me to make a seperate one?
<marcan>
yeah, there should be a separate page for these engines
<marcan>
these engines are all random little side CPUs
<marcan>
they do use a TrustZone carveout though, to share DRAM with the SEP
<daniels>
right sorry, I misread 'integrated' as 'on-CPU' rather than 'on-die'
<marcan>
basically what happened is Apple took an old iPhone, put it into a laptop, stuck an Intel CPU on the side as a coprocessor and called it a "T2 Mac"