<rqou_>
rcombs: i might not be consistently online, but i read logs periodically
<rqou_>
i've also been intermittently working on AVD but don't have much to show for it yet
<rcombs>
rqou_: hey! yeah prores will be interesting since there's not really any standard API bits for it outside of macOS… how complex is the userspace driver going to need to be?
<rqou_>
the hardware is simply "feed it a frame (and a dma descriptor) and the hardware tells you when it's done"
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
chipxxx has quit [Remote host closed the connection]
yuyichao_ has quit [Ping timeout: 480 seconds]
amarioguy has joined #asahi-dev
<rcombs>
well that's nice and simple
<rcombs>
lemme see here
<rcombs>
rqou_: is AVD/AVE similarly simple?
<rcombs>
rqou_: for prores, I think your best bet is probably gonna be to expose an V4L2_PIX_FMT_PRORES, along with various V4L2_CID_[*] controls for tuning options and such
<chadmed[m]>
AVD is a little bit more complex
<rcombs>
basically, if you'd have an easy time taking a coded packet as a single buffer and throwing it at the hardware entirely within the kernel, your best bet is probably v4l2 m2m
<rcombs>
if not, there are a bunch of other potential options to consider
<chadmed[m]>
It’s got a whole boatload of tunables, DMA regions, a big blob of firmware, multiple hardware blocks for VP9, HEVC and H.264 and a peculiar control register layout
<rcombs>
well, the biggest question is "how much work is there that could/should reasonably be offloaded to a userspace driver"
<rcombs>
like, does something have to parse packets and break them down into several smaller buffers before feeding them to the hardware?
<rcombs>
or on the encode side, does the hardware generate an intermediate format that requires substantial further processing (gluing pieces together, adding headers, etc) to produce a valid coded packet?
<rcombs>
also on encode, how much rate control feedback needs to be done in software?
<chadmed[m]>
I dont think either is the case. Jamie managed to coax a frame out of AVD just poking it from m1n1 so thats promising
<rcombs>
can you tell the encoder unit "target this bitrate for the stream" and just roll with that, or do you have to tell it e.g. what quantization settings to use for each macroblock?
<rcombs>
a lot of those more complex pieces might be better-off in a userspace driver
<rcombs>
but if it's really just "feed raw input data and high-level settings, get finalized output", then the whole thing can probably live in the kernel just fine via v4l2
<rcombs>
the other major options are VAAPI and OMX; OMX has the advantage of being very open and extensible, but has the downside of being absolute hot trash at every level
<rcombs>
VAAPI has the advantage of not sucking (and being widely-deployed in desktop usage), but the disadvantage of being potentially more complex to integrate with codecs that it doesn't already support, along with being designed to integrate at a somewhat lower level than "pass in opaque bag of bytes, get out pile of pixels"
<rcombs>
whatever you do for decode, you'll want to make sure you're capable of spitting out buffers that are in a format (or can easily be mapped by userspace code into a format) that the GL driver can import
<rcombs>
ffmpeg/mpv/etc already support doing that with drmprime buffers or VAAPI frames (which are internally drmprime dmabuf fds)
<rcombs>
but ffmpeg _doesn't_ yet support using dmabuf fds with v4l2, so if you go that route I'll need to add that :)
thelounge7571340 has quit [Remote host closed the connection]
Gaspare has joined #asahi-dev
Gaspare has quit [Quit: Gaspare]
<marcan>
sven: I want to say the stream allocation needs to happen when the DCP DRM driver actually wants to turn on an output, not when there is merely a monitor connected... but then how do you get EDID ahead of time?
<marcan>
so yeah, maybe we do have to greedily allocate DCPs as soon as anything is plugged in, due to the architecture
<marcan>
kind of sucks since ideally users would be able to use as many monitors as they want as long as they only actually turn on a certain number (this is how crtc limitations can be implemented in DRM)
<marcan>
but if we can't even get EDID without a DCP...
<marcan>
either way, we do need a DRM connector created upfront for every physical output, even if they aren't mapped to any DCPs until hotplug
snowcra5h has quit [Quit: B1tch eX]
<bluetail>
DRM=Digital rights management, DCP=?
<Capta1nT0ad[m]>
bluetail: The Direct Rendering Manager (DRM) is a subsystem of the Linux kernel responsible for interfacing with GPUs of modern video cards. DRM exposes an API that user-space programs can use to send commands and data to the GPU and perform operations such as configuring the mode setting of the display.
<Capta1nT0ad[m]>
DCP is display co-proccessor
<bluetail>
Thanks. I wrote that down since I had issues finding it through google
<Capta1nT0ad[m]>
* display co-proccessor and you won't find much about it on google
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
SSJGZ has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
chadmed has joined #asahi-dev
<jannau>
sven: pushed updates to my dcp branches which boots dcpext and uses disp0/dispext0 darts in a single domain
<jannau>
there's are 2 vblank related warning during initialization from drm but hdmi works
<jannau>
most convenient way to check if everything works is /sys/kernel/debug/dri/2/state, number might differ, its 2 for me since I have vgem enabled
<jannau>
I plan to work on dcp this weekend but I guess if I move the the dcpep code first to iomfb.c there will be little conflict if we work on it at the same time
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bisko has joined #asahi-dev
bisko has quit [Ping timeout: 480 seconds]
bisko has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
bisko has quit [Ping timeout: 480 seconds]
chadmed has quit [Remote host closed the connection]
goldsoultheory has joined #asahi-dev
<sven>
jannau: feel free to start the move, I probably won’t have much time before Monday
<jannau>
ok
<sven>
marcan: yup, I thought about that but don’t see how that’s possible with this architecture yet. Pretty sure the stream needs to be connected to DCP before we can tell anything
<sven>
konradybcio: I’ll test it later this weekend
<jannau>
sven: did you test trace_dcp.py on dcp? I get subtype 0xc0 commands with a length of 17. trace_dcp.py:321ff
thelounge7571340 has joined #asahi-dev
<sven>
uh, i think so
thelounge7571340 has quit [Remote host closed the connection]
goldsoultheory has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bisko has quit [Ping timeout: 480 seconds]
<sven>
hrm, I think I occasionally saw that invalid magic as well but just ignored it
<jannau>
the invalid magic is not the problem. I get tx.cmd's shorter than 64 bytes and empty replies instead of at least 16 bytes which breaks the parsing in handle_reply/handle_cmd
<jannau>
worked around that for now by ignoring it
goldsoultheory has joined #asahi-dev
<sven>
huh
<sven>
dont think that ever happened here
<sven>
but there is something that’s broken because I sometimes get that unmapped dart page thing
<sven>
it just happens so rarely that insider care to investigate
<sven>
*i didn‘t
goldsoultheory has quit [Ping timeout: 480 seconds]
<sven>
did you trace macOS or m1n1 there?
<jannau>
m1n1
<sven>
I never tried that
<jannau>
confirmed, doesn't happen with macos
<jannau>
dcpext somehow confuses Xorg or kde. kde's display settings shows a second monitor with an made up 1024x768 mode
<jannau>
a little concering is that the identify boxes are displayed on the hdmi connected display
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
laci has quit [Quit: Connection closed for inactivity]
<sven>
iirc the current driver always marks the screen as connected
<sven>
that probably confuses xorg
<sven>
looks like drivers/mux is a very thin abstraction that would give us devicetree bindings for the display crossbar
<sven>
konradybcio: t8103 boots with uncore_regs and fast_ipi set to false
<konradybcio>
Ok thanks, I'll send a v(n+1) soon
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<jannau>
sven: yes, already fixed. I thought it's marked at some point as not connected
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
ChaosPrincess has quit [Quit: WeeChat 3.6]
ChaosPrincess has joined #asahi-dev
bisko has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has quit [Remote host closed the connection]
fossdd has joined #asahi-dev
<sven>
how many dispext/dcpext does the largest SoC have right now?
<sven>
3 for each die?
<sven>
jannau: can you run [hex(read32(u.adt["/arm-io/atc%d-dpxbar" % i].get_reg(0)[0] + 0x800)) for i in range(N)] on a multi die SoC and replace N with the number of atcphys there?
bisko has joined #asahi-dev
<sven>
and a ADT from a multi-die soc would also be very useful
<jannau>
I think 4 per die on the m1 max
<sven>
ah, yes, 4 makes sense.
<sven>
i just had an off-by-one error
<jannau>
ultra has dcpext7
<sven>
on a single die? huh
<jannau>
on both dies
bisko has quit [Ping timeout: 480 seconds]
<sven>
ok, would be interesting to see the initial value of that crossbar register i mentioned above
<sven>
essentially unrouted dispext inputs are stuck at 1 there
yuyichao_ has joined #asahi-dev
<jannau>
sven: all zero: ['0x0', '0x0', '0x0', '0x0', '0x0', '0x0']
<sven>
display-crossbar0 in the ADT claims 16 UFP which matches 8 x dcpext and 2 streams/dcpext
<jannau>
I guess we could try if the front thunderbolt ports support display out
<sven>
there is a single xbar for each atcphy
<sven>
the weird part is the dcpextN,M input side
<sven>
i assumed there should be 16 of those per crossbar but there seem to be 9
skoobasteeve has quit []
bisko has joined #asahi-dev
skoobasteeve has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<marcan>
jannau: they do, I tried that
<marcan>
sven: 8 (4x DCPEXT on one die) + StreamCodec
<sven>
StreamCodec?
<marcan>
that's one of the ProRes blocks
<marcan>
most likely related to their secret VR project
<sven>
ah, lol
<marcan>
so this sounds like there is no inter-die routing
<sven>
so I guess they hardcoded that rouing can only happen within a single die somewhere
<sven>
*routing
<marcan>
which makes sense, because why would you actually want that? one die can drive all of its ATCs
<sven>
yeah, I would've just expected to see that represented in the ADT
<marcan>
not the first time the ADT lies
<sven>
but then again, the ADT is full of hacks anyway
<jannau>
but shouldn't there then be a second crossbar on the second die and it should be possible to drive 6 6k displays
<marcan>
yes
<marcan>
just add the die offset to the xbar regs, does it exist?
<sven>
note that there is "crossbar" and "dpxbar" in the ADT
<sven>
crossbar is their fake top-level node that decides routing
<sven>
dpxbar is actual HW and there's one of those per ATC
<marcan>
ah, then yeah, it all checks out
bisko has quit [Ping timeout: 480 seconds]
<sven>
yeah, I guess in their "fake crossbar kext" they just hardcoded that it will only match a dpxbar and a dcpext from the same die
<marcan>
and if I had to guess a realistic reason for the 4 display limitation, something something real time memory bandwidth limits? though it doesn't make much sense considering how much real bandwidth this thing has. could also just be marketing / keeping both Studio variants equal
<sven>
I'm pretty sure that they could also support two external screens on the normal M1 if they modified their DCP firmware a bit. my guess is marketing ;)
<marcan>
re hack mode support, DCP does two layers right?
<sven>
layers?
<marcan>
display layers
<marcan>
per display
<marcan>
planes
<jannau>
at least 2
<marcan>
can we just take one for each output stream and support separate streams with separate FBs that way, at the cost of losing the cursor plane or similar? probably a lot nicer to the compositor than trying to do something horrible with fake-tiled framebuffers
<marcan>
internally you'd just tile it in space and have the layers not overlap
<sven>
don't know yet
<marcan>
(this would require some funky logic in the driver to allocate DCPs discretely first, then start oversubscribing them if the user turns on too many outputs)
<marcan>
but it would also allow 4 displays on the M1 Pro machines, which is cute
<sven>
the actual implementation will be pretty cursed if it works out, yes
<marcan>
what I don't know is how it deals with EDIDs and modes
<marcan>
like does it only work with identical displays?
<sven>
no idea yet, it's still all very vague
<marcan>
(would still be very useful, I have an IVB laptop with that exact limitation)
<marcan>
(3 displays, two have to have the same clock)
<sven>
so far I just have an idea how to convince it to connect two streams and probably how to route them to separate atcs
<sven>
no idea what iomfb itself does. i'll probably annoy dottedmag for more traces once I get there
<marcan>
heh
<marcan>
dunno if I mentioned we have an apple studio display donor
<sven>
but on the trace from yesterday it looked very similar to the situation when just a single screen was connected
<marcan>
you're in line for that if you sign up for it ;)
<marcan>
(otherwise I'll get it, when I have the bandwidth for this)
<sven>
i feel like i've already signed up for this cursed mess when I wanted thunderbolt anyway :D
<sven>
what is that display anyway? just thunderbolt with some special usb devices?
<marcan>
probably
<marcan>
well, I wouldn't be surprised if it has some cursed thunderbolt stuff a la T2
bisko has joined #asahi-dev
<marcan>
but the display stuff should be standard I'd hope
<sven>
I assume it also works on the m1 non-pro/max?
<marcan>
I assume so? it'd be dumb for it not to
<sven>
lol, apparently it essentially runs ios
<jannau>
t8103 supports pro display xdr, so it should support the the studio display
<marcan>
sven: yup
<marcan>
hence why I said the T2 thing
<sven>
ofc it also has firmware updates
<sven>
yeah, I guess I could do that. probably a nice test case for thunderbolt anyway
<marcan>
you're in .de right? I can ping the sponsor about this, maybe just wait until next week :)
<sven>
sure
bisko has quit [Ping timeout: 480 seconds]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<sven>
okay, i think apple collects the valid dispext<->dpxbar connections inside a "domain" and the ADT then has dp-switch-ufp-domain
<sven>
which is zero for everything on the first die and one for everything on the second die
<sven>
and then dfp-switch-ufp-endpoint encodes the index inside the dpxbar
<sven>
so that all makes sense now
mokou has joined #asahi-dev
<jannau>
marcan: any objections over using a custom header with the payload size for initramfs payloads?
<jannau>
that makes it simple to support concatenated cpio archives and we can rely on the kernel for decompression (for zstd support)
<jannau>
only mildly annoying part is writing binary numbers from shell scripts like run_guest_kernel.sh
teul[m] has joined #asahi-dev
skoobasteeve has quit [Ping timeout: 480 seconds]
skoobasteeve has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
jluthra has quit [Remote host closed the connection]
jluthra has joined #asahi-dev
snowcra5h has joined #asahi-dev
snowcra5h has quit [Quit: B1tch eX]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
tired has quit [Quit: /]
tired has joined #asahi-dev
tired has quit [Quit: /]
tired has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<amarioguy>
quick question if you're submitting a "v2" patch should you include a link to the v1 version as well?
<amarioguy>
and should that go after the '---' part or before as a rule of thumb?
skoobasteeve has quit [Quit: No Ping reply in 180 seconds.]
skoobasteeve has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
kov has joined #asahi-dev
<jn>
amarioguy: i tend to include it. i put it after the dash line, because i think it's irrelevant for the final commit once applied to git
SSJGZ has quit [Ping timeout: 480 seconds]
chipxxx has joined #asahi-dev
arekm has quit [Quit: leaving]
arekm has joined #asahi-dev
goldsoultheory has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
* amarioguy
has sent v2 of a patch to mailing lists, hopefully correctly this time