media: apple: avd: t8103: size the VP instruction FIFO limit correctly

[kcirtapfromspace]

t8103_configure_stream() programs AVD_V3_VP_INSN_FIFO_MASK to 0x100000
while fifo_size() allocates 0x100000 * 12, so the limit describes a twelfth
of the buffer it points at. A frame whose instruction stream exceeds 1 MiB wraps
inside the larger allocation and the hardware never signals completion:
avd_watchdog_func() fires two seconds later with Frame processing timed out!
and the client gets zero decoded frames.

Every real 1080p H.264 keyframe is large enough to hit this, so H.264 failed on
the first frame of essentially any real-world stream. HEVC and VP9 were
unaffected even at larger coded sizes — a 1080p VP9 clip with a 127 KiB keyframe
decodes cleanly while H.264 fails 10/10 at 140 KiB. That asymmetry is what
pointed here: it rules out shared buffers and anything codec-agnostic, and
t8103 is the only variant that programs a nonzero value in this register.

Deriving it from fifo_size() rather than hardcoding a second constant keeps the
two from drifting apart again.

Measured

MacBook Pro 13" M1 (j293/t8103), on asahi-wip at ccce11a, 10 decode runs per
clip via ffmpeg + VA-API:

clip	keyframe	before	after
synthetic 1080p	89 KiB	10/10	10/10
synthetic 1080p	140 KiB	0/10	10/10
real-world 1080p	384 KiB	0/10	10/10

Correctness against libavcodec, per-frame PSNR (inf = bit-exact):

stream	before	after
H.264 real-world 1080p	no output	y:inf u:inf v:inf
HEVC real-world 1080p	y:inf u:inf v:inf	y:inf u:inf v:inf
VP9 real-world 1080p	y:inf u:inf v:inf	y:inf u:inf v:inf

Reproducer, if useful:

ffmpeg -y -f lavfi -i "testsrc2=size=1920x1080:rate=30:duration=1,noise=alls=8:allf=t" \
       -c:v libx264 -profile:v main -pix_fmt yuv420p -qp 31 big.mp4 </dev/null
ffmpeg -y -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i big.mp4 \
       -frames:v 5 -pix_fmt nv12 -f rawvideo /dev/null </dev/null

Notes

Testing used a VA-API driver package
built around sofus13's libva-v4l2_request fork, plus a package for the avd-fw
firmware, since neither is currently packaged for Arch Linux ARM.

Five other hypotheses were built and measured before this one and all were
falsified — the 8x8 transform path, pps_tile[0] sizing, the multi-slice
readl_poll_timeout, a lost mailbox interrupt under IRQF_ONESHOT, and the
H.264 slice-offset scan. Recording that in case any of them looks tempting later.

Two smaller things noticed while working in this file, not included here and
happy to send separately if wanted:

• stream_scaling() dereferences run->scaling_matrix without a NULL check,
  and that control is optional (run->scaling_matrix = ctrl ? ctrl->p_cur.p : NULL). A client that sets pic_scaling_matrix_present_flag without supplying
  the control would oops.
• H.264 has no data_byte_offset (HEVC does), so stream_slice() re-derives it
  by scanning for emulation-prevention bytes with an unbounded data[off] read.
  It measured correct on every stream tested, but it is an out-of-bounds read on
  malformed input.

I also independently hit the weighted-prediction bug that #581 fixed, and can
confirm that fix resolves it — weighted_bipred_idc being applied to P slices
put luma about 54 dB off. Arrived at the same place from the other direction.

[WhatAmISupposedToPutHere]

why is it here, put it in the commit message instead.

[WhatAmISupposedToPutHere]

you do not need to generate a wall of slop to describe a one line change, rewrite the pr description in your own words, it should not be difficult.

[sofus13]

thats kinda weird, hevc's instructions should be bigger than h264.
Would you mind testing with 0 instead?
I would prefer getting dart errors until i size fifo_size correctly

[jannau]

Writing 0 works as well, fixed in asahi-7.1.12-1 as fixup commit. Thanks for finding this issue