ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | Non-development talk: #asahi | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
tenkuu has quit [Ping timeout: 480 seconds]
<janneg>
eiln: bed time reading through you avd notes
<janneg>
doo not read through the full itu h.264 spec
<janneg>
start with historic versions without svc and mvc
phire has quit [Quit: No Ping reply in 180 seconds.]
phire has joined #asahi-dev
dcow has quit [Ping timeout: 480 seconds]
hex-spell has quit [Quit: WeeChat 4.0.5]
gabuscus has quit []
<lina>
janneg: Mirroring is always an application thing, as far as I know no webcam mirrors the image internally
<lina>
(Some probably have toggles for it but it should never be the default and I think videocall apps always mirror internally)
<lina>
So we don't need to worry about that
<lina>
After all when you send the image to other people they see the unmirrored version, mirroring is only for local preview
dcow has joined #asahi-dev
dcow has quit [Ping timeout: 480 seconds]
<chadmed>
eiln: since the cm3 fw is uploaded by the kernel, we can write our own and use that as the copro for stateless >:)
<chadmed>
R was already considering this iirc
phire has quit [Remote host closed the connection]
phire has joined #asahi-dev
dcow has joined #asahi-dev
jnn has joined #asahi-dev
jn has quit [Ping timeout: 480 seconds]
dcow has quit [Ping timeout: 480 seconds]
gabuscus has joined #asahi-dev
DannyB has joined #asahi-dev
dcow has joined #asahi-dev
cylm has quit [Ping timeout: 480 seconds]
dcow has quit [Ping timeout: 480 seconds]
dcow has joined #asahi-dev
tristan2_ has joined #asahi-dev
tristan2 has quit [Ping timeout: 480 seconds]
dcow has quit [Ping timeout: 480 seconds]
dcow has joined #asahi-dev
dcow has quit [Ping timeout: 480 seconds]
espo has quit [Remote host closed the connection]
espo has joined #asahi-dev
dcow has joined #asahi-dev
dcow has quit [Ping timeout: 480 seconds]
dcow has joined #asahi-dev
dcow has quit [Ping timeout: 480 seconds]
dcow has joined #asahi-dev
dcow has quit [Ping timeout: 480 seconds]
dcow has joined #asahi-dev
dcow has quit [Ping timeout: 480 seconds]
hightower2 has quit [Ping timeout: 480 seconds]
dcow has joined #asahi-dev
crabbedhaloablut has joined #asahi-dev
dcow has quit [Ping timeout: 480 seconds]
dcow has joined #asahi-dev
dcow has quit [Ping timeout: 480 seconds]
dcow has joined #asahi-dev
dcow has quit [Ping timeout: 480 seconds]
ydalton has joined #asahi-dev
<ydalton>
chadmed: that would also mean avoiding the problem of copying a macOS blob
cyrinux has quit []
cyrinux has joined #asahi-dev
ydalton has quit [Ping timeout: 480 seconds]
hex-spell has joined #asahi-dev
dcow has joined #asahi-dev
dcow has quit [Ping timeout: 480 seconds]
dcow has joined #asahi-dev
dcow has quit [Ping timeout: 480 seconds]
dcow has joined #asahi-dev
dcow has quit [Ping timeout: 480 seconds]
dcow has joined #asahi-dev
<eiln>
janneg: that is much saner, thank you
<eiln>
chadmed: I meant that as in "I don't want to deal with the CM3 at all" e.g. non-aic interrupts, writing cortex code, etc. I did load my own code at the end ;)
<eiln>
I'm tempted to generate the decode stream entirely in userspace and attach it as VIDIOC_S_EXT_CTRLS() V4L2_CTRL_FLAG_HAS_PAYLOAD void* ptr. header/reference frame info is all encoded in there. that would make our driver about 500 LOC
<eiln>
we'll need a userspace layer anyway; apple rolls out NEON in the kernel to untile output
<chadmed>
oh.... ew
<eiln>
I thought about using ane's chinook but it seems iboot locks down ctrr since 13.5
<janneg>
eiln: they do what (RE: neon)! neither scaler or gpu can handle the AVD tiling?
<janneg>
if svc and mvc were just annexes they could be easily ignored but unfortunately they seeep through the whoole standard and add complexity
DannyB has quit [Ping timeout: 480 seconds]
<eiln>
janneg: yes they have de/tileRows fn in the kext. codec/platform invariant
<eiln>
I know avc is scaled because my output can't fit in that tile size. there's a hardcoded scaling list. I have yet to seen anything about scaler
<janneg>
if we need an userspace part we should reconsider va-api or vulkan video as those have already userspace
<chadmed>
how would that userspace component slot in then? i initially imagined a va-api driver but it doesnt have v4l2 as a backend
<eiln>
as a render node?
<chadmed>
oh does that mean a drm driver for avd?
<janneg>
I haven't looked at libva internals but I suppose we could / have to whatever we want as backend and driver
DannyB has joined #asahi-dev
<chadmed>
the backends are modular so we could theoretically just add one for v4l2
<chadmed>
i just think no one's bothered doing it yet :
<janneg>
vulkan video would probably mean a drm mode
dcow has quit [Ping timeout: 480 seconds]
<janneg>
not sure how happpy v4l2 is about a custom which pipes basically binary data through
<ChaosPrincess>
if they are not happy, char/misc exists
<ChaosPrincess>
or pretend the avd is totally a part of gpu.
<janneg>
the only appeal of v4l2 m2m stateless is that it is a standardized API
<eiln>
ok yeah sps+pps is part of the decode stream
<eiln>
we are decoding smpte bars now. pow2 64 <= height,width <= 4096 works. shall look into tiling tomorrow
<eiln>
it's so ugly. just height/width looks like this ((((x.height - 1) << 1) >> 4) << 16) | (((x.width - 1) << 1) >> 4)
<janneg>
64 and 4096 are reasonable minimal/maximal dimensions
<janneg>
any idea why the dimensions are effectively just shifted right by 3?
<janneg>
I would expect ((width + 15) >> 4) - 1
<janneg>
i.e. SPS.pic_width_in_mbs_minus1
<eiln>
janneg: that makes much more sense. I haven't even tested non-pow2
dcow has joined #asahi-dev
<eiln>
the decode stream is roughly about 10 frame info u32s (height/width), 10 shifted dart addrs, and 10*n slice commands which are 0x2a000000 masked
<janneg>
is the 10 constant? does your h264 bitstream has a single slice or multiple?
<eiln>
only single slice but it's been constant for all of these
<janneg>
I guess the dart addresses could point to reference frames or scaling_lists
<janneg>
H.264 (03/2005) is the best spec document to look at
<chadmed>
bootlin have a v4l2 vaapi driver implementing the request api
dcow has quit [Ping timeout: 480 seconds]
hightower2 has joined #asahi-dev
hightower3 has joined #asahi-dev
hightower2 has quit [Read error: Connection reset by peer]
dcow has joined #asahi-dev
dcow has quit [Remote host closed the connection]
dcow has joined #asahi-dev
DannyB has quit [Ping timeout: 480 seconds]
<eiln>
janneg: just decoded a non-idr coded slice. structure is no longer the same, additional dart addrs pointing to the previous (presumably) reference frames
dcow has quit [Ping timeout: 480 seconds]
<eiln>
the next dma'd decode stream automatically stacks on top of the last one. interesting. that limit must be 0x100000 then
AnuthaDev has quit []
AnuthaDev has joined #asahi-dev
<janneg>
just additional pointers or changes in the decoder headers as well? I would expect 2 reference frame lists. might be hard to detect if you just decode 2 frames
<eiln>
header changes from 0x2db032e0->0x2db012e0, 0x100000->0x300000, same otherwise
AnuthaDev has quit []
dcow has joined #asahi-dev
PatRyk has joined #asahi-dev
<eiln>
**coded non-idr slice above, typo
<eiln>
decoded the next next non-idr slice, it's [height/width, dmaconfig, dst_y, dst_uv, dmaconfig, dmaconfig, dmaconfig, dmaconfig, unk_0, ref_tile0_0, ref_tile0_1, ref_tile0_2, ref_tile0_3, unk_1, ref_tile1_0, ref_tile1_1, ref_tile1_2, ref_tile1_3]
<eiln>
aha that's list0 and list1
dcow has quit [Ping timeout: 480 seconds]
jeisom has joined #asahi-dev
roxfan2 has quit [Ping timeout: 480 seconds]
hightower3 has quit [Read error: Connection reset by peer]
hightower3 has joined #asahi-dev
roxfan has joined #asahi-dev
DannyB has joined #asahi-dev
hightower3 has quit [Read error: Connection reset by peer]
hightower2 has joined #asahi-dev
cylm has joined #asahi-dev
Yannik_Sc has joined #asahi-dev
PatRyk has quit [Ping timeout: 480 seconds]
tenkuu has joined #asahi-dev
hightower2 has quit [Remote host closed the connection]
DannyB has quit [Ping timeout: 480 seconds]
Yannik_Sc has quit [Quit: Leaving]
tenkuu has quit [Quit: WeeChat 4.0.4]
DannyB has joined #asahi-dev
hightower2 has joined #asahi-dev
<kettenis>
marcan: it seems the join_pref command fails on bcm4388
<kettenis>
do you see the same on Linux?
dcow has joined #asahi-dev
espo has quit [Quit: WeeChat 4.0.4]
espo has joined #asahi-dev
<janneg>
kettenis: quoting from somewhere else: "there's a join_pref error I haven't looked at yet (it looks like a variable size/tagged struct, not sure why it fails) but it's nonfatal"
<kettenis>
thanks, the openbsd driver makes it fatail, but I hacked around that