Adds 0008-panvk-bifrost-bump-max-image-dim-3d-for-dawn.patch. Two-hunk patch:
Hunk 1: Bumps maxImageDimension3D from 512 to 2048 on Bifrost (PAN_ARCH 7..10).
Surfaced by panvk-bifrost-perf-measurement iter1 spike: Brave's WebGPU/Dawn
detects panvk-bifrost as a Vulkan adapter on Mali-G52 r1 MC1 but rejects it
because the advertised limit is below WebGPU's 2048 minimum (per
third_party/dawn/src/dawn/native/vulkan/PhysicalDeviceVk.cpp:746). This is
the actual unblock for the campaign's stated motivator — Chromium GPU
process Vulkan boot on PineTab2 / Bifrost SBCs.
Per Vulkan 1.3 spec §43.1, maxImageDimensionXD is the upper bound on any
creatable image; per-format limits MAY be smaller. On PAN_ARCH<=10 the
per-format limit caps at ~1023 per axis for RGBA8 within the 4 GB
max_img_size_B address constraint. Apps trying 2048^3 with thick formats
hit the per-format limit at image-create — per-spec behavior.
Hunk 2: Removes three asserts in get_max_3d_image_size() that encoded the
wrong invariant (per-format >= basic), opposite of what the Vulkan spec
mandates. The asserts were release-mode-masked via NDEBUG, but debug
builds would abort the first time Dawn (or any client) called
vkGetPhysicalDeviceImageFormatProperties on a 3D image format. Surfaced
by Phase 5 2nd-model review.
Verified on PineTab2 (Mali-G52 r1 MC1, PAN_ARCH 7):
- vulkaninfo: maxImageDimension3D = 2048
- Brave/Dawn: "Insufficient Vulkan limits" warning eliminated; adapter
accepted for WebGPU.
- CTS regression: dEQP-VK.api.copy_and_blit.core.image_to_image.3d_images.*
6/6 Pass (unchanged from r7 baseline).
Phase 5 (2nd-model) review: APPROVE WITH CHANGES — both changes applied
(release-mode + debug-mode assert exposure addressed by removing the
wrong-invariant asserts).
Note on numbering: r8 was attempted (KHR_depth_clamp_zero_one trim) but
abandoned mid-Phase-3 when it surfaced that 5 more post-1.3.10 KHR
extensions are advertised — surgically false-gating all of them would
risk undoing r1's KHR_robustness2 work for Chromium Dawn. Documented at
~/src/panvk-bifrost/iter21/phase0to3_close_no_ship.md.
Cross-refs:
- ~/src/panvk-bifrost/iter22/phase0to2_max3d_close.md (Phase 0-2 close)
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Substitutes c->v_loop_filter_chroma_intra and c->h_loop_filter_chroma_intra
with daedalus wrappers in the bit_depth=8 / chroma_format_idc<=1 (4:2:0)
branch. 4:2:2 stays on the in-tree NEON path (the daedalus chroma intra
dispatch is 4:2:0-only).
The fourier dispatches were exposed in PR #11 (DEFINE_INTRA_DISPATCH
macro generates the public daedalus_dispatch_h264_deblock_chroma_*_intra
symbols + recipe wrappers).
Re-architects the chroma init: v_loop_filter_chroma_intra was previously
assigned unconditionally to the NEON variant (which works for both 4:2:0
and 4:2:2). We now assign it INSIDE both branches of the chroma_format_idc
conditional — 4:2:0 picks daedalus, 4:2:2 keeps NEON. No regression for
4:2:2 streams.
Same NEON-to-NEON via recipe shape as 0010 luma intra.
Closes the deblock substitution layer for the 4:2:0 / 8-bit hot path:
- 0005 luma_v non-intra ✓
- 0008 luma_h non-intra ✓
- 0009 chroma_v / chroma_h non-intra ✓
- 0010 luma_v / luma_h intra ✓
- 0013 chroma_v / chroma_h intra ✓
All 8 deblock variants for the common 4:2:0 path now route through
daedalus. 4:2:2 chroma + the chroma422 mbaff variants stay on in-tree
NEON.
Verified the patch applies cleanly on top of 0001-0012 against the
pinned upstream commit b57fbbe5 on hertz.
Closes the H.264 qpel substitution. Extends 0007 (which routed only
mc20 put_) to ALL 15 useful positions in BOTH the put_ and avg_
tables, skipping mc00 (integer copy / pointer-only fast path).
29 substitutions total: 14 new put_ + 15 avg_. Each wraps a single
daedalus_recipe_dispatch_h264_qpel_{avg_,}mcXY call (the dispatches
landed in daedalus-fourier PRs #15-#20). Collapsed via a single
DEFINE_QPEL_WRAPPER macro on the libavcodec shim side so the diff
is uniform.
All recipe-table entries route AUTO to CPU NEON — no QPU shaders
for any qpel position other than mc20 yet. Plumbing-only
NEON-to-NEON via the daedalus recipe layer; bit-exact against
the in-tree ff_*_h264_qpel8_*_neon path (each daedalus dispatch is
already bit-exact-gated by the corresponding fourier PR's test).
16x16 qpel tables ([0][...]) stay on the in-tree NEON. daedalus
only exposes 8x8 today; 16x16 substitution can land once fourier
provides those variants.
Verified the patch applies cleanly on top of 0001-0011 against the
pinned upstream commit b57fbbe5 on hertz.
Substitutes H264DSPContext.chroma_dc_dequant_idct in the 4:2:0 /
bit_depth=8 init path with a wrapper that composes the daedalus
chroma DC Hadamard primitive (daedalus-fourier PR #25) with the
qmul scaling FFmpeg's reference does in one fused function
(h264idct_template.c::ff_h264_chroma_dc_dequant_idct).
Algorithm per H.264 §8.5.11.1 / §8.5.11.2:
1. Extract 4 DCs from the scattered positions in the per-MB
coefficient buffer (stride=32, xStride=16)
2. 2x2 Hadamard transform (daedalus primitive)
3. qmul scale + >> 7, write back to original positions
Bit-exact against ff_h264_chroma_dc_dequant_idct_8_c. The Hadamard
itself is gated by the fourier PR #23 7-case test suite (including
the H·H = 4·I algebraic invariant), and the public-API parity
test added in PR #25 confirms the src/ symbol matches the test ref.
4:2:2 chroma stays on the in-tree ff_h264_chroma422_dc_dequant_idct_c
path — same chroma_format_idc<=1 gating shape as 0009 chroma deblock.
Pin bump: _daedalus_fourier_commit / DAEDALUS_FOURIER_COMMIT bumped
to b9f9ff2a (post-PR #25) so the build picks up the public
daedalus_h264_chroma_dc_hadamard_2x2 symbol.
Verified the patch applies cleanly on top of 0001-0010 against the
pinned upstream commit b57fbbe5 on hertz.
Adds the bS=4 intra-strength variants of the already-substituted
luma_v / luma_h deblock (0005, 0008). Intra MBs and certain
inter-MB edges (4x4 transform boundaries inside an Intra_NxN
neighbour) force boundary strength to 4 per H.264 §8.7.2.1.
H264DSPContext.v_loop_filter_luma_intra →
daedalus_recipe_dispatch_h264_deblock_luma_v_intra
H264DSPContext.h_loop_filter_luma_intra →
daedalus_recipe_dispatch_h264_deblock_luma_h_intra
Both kernels landed in daedalus-fourier PR #11. Recipe → CPU NEON
(no intra QPU shaders yet); plumbing-only NEON-to-NEON via daedalus.
Signature differs from bS<4: no tc0 argument. Wrapper passes
daedalus_h264_deblock_meta with alpha/beta set; tc0[] is ignored by
the intra dispatch (bS=4 hardcodes the strength).
Chroma intra variants are deferred to a follow-up because the chroma
init has a 4:2:0 / 4:2:2 split (chroma_format_idc gating) — the
daedalus dispatch is 4:2:0-only and needs explicit conditional
substitution to avoid running on 4:2:2 chroma.
Verified the patch applies cleanly on top of 0001-0009 against the
pinned upstream commit b57fbbe5 on hertz.
Chroma siblings of 0005 (luma_v) and 0008 (luma_h). Same
NEON-to-NEON pattern via the daedalus recipe layer:
H264DSPContext.v_loop_filter_chroma →
daedalus_recipe_dispatch_h264_deblock_chroma_v
H264DSPContext.h_loop_filter_chroma →
daedalus_recipe_dispatch_h264_deblock_chroma_h
Both kernels landed in daedalus-fourier PR #10. Recipe table routes
AUTO to CPU NEON (no chroma QPU shaders yet), so this is plumbing-
only and stays bit-exact against the in-tree NEON.
Intra chroma (bS=4) loop filters remain on in-tree NEON;
daedalus_h264_deblock_meta covers the non-intra (bS<4) path.
Verified the patch applies cleanly on top of 0001-0008 against the
pinned upstream commit b57fbbe5 on hertz. Wires the new patch into
both arch/PKGBUILD and debian/build-deb.sh.
Adds patch 0008 to the substitution arc, mirroring 0005's V variant
for H.264 non-intra bS<4 horizontal luma deblock.
H264DSPContext.h_loop_filter_luma →
daedalus_recipe_dispatch_h264_deblock_luma_h
The H kernel was added to daedalus-fourier in PR #9 (vendored
ff_h264_h_loop_filter_luma_neon, wired through the same CPU-dispatch
pattern as V). Recipe table routes AUTO to CPU NEON (no QPU shader
for H yet), so this is a NEON-to-NEON substitution via the daedalus
recipe layer — same shape as 0005.
The libavcodec.so ctx remains no-QPU (daedalus_ctx_create_no_qpu),
matching the existing 0003/0004/0005/0007 patches. Higher-cycle
QPU init waits for a feature-flag gating change in a separate PR.
Intra (bS=4) h_loop_filter_luma_intra stays on the in-tree NEON .S
code; daedalus_h264_deblock_meta covers the non-intra path only.
A follow-up can route intra once daedalus-fourier exposes the
intra-h dispatch (the kernel already exists internally per fourier
PR #11).
Wires the new patch into both arch/PKGBUILD and debian/build-deb.sh
sequences. Verified the patch applies cleanly on top of 0001-0007
against the pinned upstream commit b57fbbe5 on hertz.
Adds 0007-panvk-bifrost-xfb-component-base-fix.patch — eliminates a
reliable SIGSEGV in vkCreateGraphicsPipeline whenever an XFB-bound
vertex output is declared with non-zero `layout (component=N)`.
Surfaced by dEQP-VK.transform_feedback.simple.holes_vert (Mali-G52 r1
MC1, PAN_ARCH 7). Backtrace lands 11 frames into libvulkan_panfrost.so
called from vkt::TransformFeedback::TransformFeedbackHolesInstance::
iterate.
Root cause: iter17's lower_xfb_output_iter17 (and upstream
pan_nir_lower_xfb, which has the identical `// TODO`) computes the
source-channel mask as `mask << channel_idx`, where channel_idx is
the varying-location component (0..3) but src only contains channels
starting at nir_intrinsic_component(intr). For a scalar declared
component=2, the lowering computed `mask << 2` against a 1-component
src — out-of-range; the malformed nir_def segfaulted in downstream
NIR constant-folding (nir_constant_expressions.c::evaluate_*).
Fix translates channel_idx to source-channel space by subtracting
nir_intrinsic_component(intr) before shifting the mask, and replaces
the elided release-mode asserts with explicit release-mode guards
(closes the same elision class as the original bug).
Verified on PineTab2 (Mali-G52 r1 MC1, PAN_ARCH 7) against vulkan-cts
1.3.10.0:
- holes_vert / holes_extra_draw_vert no longer SIGSEGV (now Fail
on color-check; that is a separate iter20 finding).
- basic_*: 36/36 Pass. depth_clip_*: 1 Pass + 4 NotSupported.
lines_or_triangles*: 16 NotSupported. 0 Fail across the set.
Caveat (not regressions): max_output_components_64/_128/_256 were
never reached on the r5 sweep — watchdog killed transform_feedback
after the holes_vert crash. With this fix in place, they now run
and surface their own pre-existing coredumps, confirmed on shipped
r6 baseline too. iter20+ territory.
Phase 5 (2nd-model) review: APPROVE WITH CHANGES (non-blocking).
Changes applied: release-mode defensive guards on both preconditions
plus a dispatcher-side comment clarifying the i*2+j semantics.
Cross-refs:
- ~/src/panvk-bifrost/iter19/phase{0,1,2,3}_holes_vert*.md
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
aish is an AI-augmented conversational shell in LuaJIT 2.x with FFI
bindings to libcurl, GNU readline, and libc — no C extensions, no
build step. Source-of-truth: git.reauktion.de/marfrit/aish, tag v0.1.0
(tarball sha256 9ebc3939e028832e39391ae33efacb5ec9bcd99d123cbc8ca1cd6ca9a640b5b5).
The arch and debian recipes mirror the lmcp pattern (pure-Lua any-arch
package, no makefile, install copies modules directly):
arch/aish/PKGBUILD — depends=(luajit readline curl)
debian/aish/build-deb.sh — pure dpkg-deb, SOURCE_DATE_EPOCH pinned
debian/aish/debian/{control,changelog,copyright}
Install layout, matching what main.lua's script-dir-relative package.path
expects after the wrapper execs `luajit /usr/share/lua/5.1/aish/main.lua`:
/usr/bin/aish ← bin/aish wrapper
/usr/share/lua/5.1/aish/{main,broker,context,executor,history,
mcp,renderer,repl,router,safety,secrets}.lua
/usr/share/lua/5.1/aish/ffi/{curl,libc,pty,readline}.lua
/usr/share/lua/5.1/aish/vendor/dkjson.lua
/usr/share/doc/aish/{README.md,LICENSE,examples/config.lua}
CI: two new jobs in .gitea/workflows/build.yml at the end of file.
aish-any chains needs:lmcp-debian (parallel-DAG with claude-his-any,
serialized via the shared arch-aarch64 runner — avoids needless wait
through the unrelated fourier stack). aish-debian chains needs:aish-any.
Both invoke the standard check-already-published.sh fast-skip on no-
change pushes.
Sonnet review (per feedback_reviews_use_sonnet.md + bugfix-process
step 4): no blockers. Folded in two findings before commit: switched
needs: from mpv-fourier-aarch64 to lmcp-debian (cleaner DAG, faster
cold-build wall clock), removed the dead Build-Depends: debhelper-
compat line from debian/aish/debian/control (build-deb.sh doesn't
use debhelper).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Backports Mesa main's unconditional flip of VK_EXT_legacy_dithering.
Pure-software composition; no new HW path. vk_render_pass already gates
on enabled_features.legacyDithering and panvk_vX_blend + pan_format
already plumb the dithered BLEND descriptor (BFMT2 table has MALI_BLEND_AU
encodings for RGB565/RGB5A1/RGBA4/RGB10A2 on PAN_ARCH 7). Our r5 base
just hadn't picked up the cherry-pick.
Phase 7 verify on ohm (PineTab2 / RK3566 / Mali-G52 r1 MC1) with a
locally-built r6 lib at /tmp/r6_test_lib/:
Feature advertisement:
r5: VK_EXT_legacy_dithering not in extension list, legacyDithering=false
r6: VK_EXT_legacy_dithering rev 2 advertised, legacyDithering=true
dEQP subsets (delta):
dEQP-VK.api.*.legacy_dithering* r5/r6 both: 2 P / 0 F (identical)
dEQP-VK.renderpass.dithering.* r5/r6 both: 0 P / 0 F / 94 NS (identical)
dEQP-VK.renderpass2.dithering.* r5/r6 both: 0 P / 0 F / 94 NS (identical)
Net: zero regressions, advertisement-only delta as expected.
Second-model review (per bugfix-process step 4) traced the full code
path through vk_render_pass + panvk_vX_cmd_draw + panvk_vX_blend +
pan_format BFMT2. No interaction with our r1 nullDescriptor (disjoint
paths). Mesa upstream marks ext DONE for panvk in docs/features.txt.
ARM's own libmali r51p0 driver (BXODROIDN2PL, 2024-08) lists
VK_EXT_legacy_dithering in its Vulkan extension string table,
confirming the feature is shipped by ARM for Mali-G52-class hardware.
Follow-up out of scope: the 94 renderpass-dithering tests show as
NotSupported on both r5 and r6 — there's a separate panvk-side
prereq the dEQP harness checks (likely a specific format-feature
combination). Worth investigating in a future iteration.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Arch: version 147→148, drop enable_nacl (removed upstream), fix
nv12-external-oes patch context for 148 (base/numerics/safe_conversions.h
include removed upstream). Header comment updated: native build fiction →
cross-compile reality.
Debian: new build-deb.sh that assembles .deb from pre-built artifacts
on CT 220 (data). Same binary artifacts as the Arch package, launcher at
/usr/bin/chromium-fourier (no Conflicts with stock chromium on Debian).
Both packages published to packages.reauktion.de:
- Arch: marfrit/aarch64/chromium-fourier 1:148.0.7778.178-1
- Debian: trixie+bookworm/main/arm64 chromium-fourier 1:148.0.7778.178-1
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Backports Mesa main's unconditional flip of .fragmentStoresAndAtomics
to true in src/panfrost/vulkan/panvk_vX_physical_device.c. Closes
the Dawn-WebGPU adapter rejection at PhysicalDeviceVk.cpp:250 that
caused brave-vulkan to fall back to the SwiftShader CPU adapter on
PineTab2/Mali-G52, per marfrit/panvk-bifrost#2.
Phase 7 verify on ohm (PineTab2, RK3566, Mali-G52 r1 MC1) with a
locally-built r5 lib installed to /tmp/r5_test_lib/:
dEQP-VK.glsl.atomic_operations.*:
r4: 48 pass / 0 fail / 992 NotSupported (1040 total)
r5: 80 pass / 0 fail / 960 NotSupported (1040 total)
delta: +32 newly-passing, zero new failures
dEQP-VK.image.store.*:
r4: 2772 pass / 0 fail / 238 NotSupported (3010 total)
r5: 2772 pass / 0 fail / 238 NotSupported (3010 total)
delta: identical (image.store is independent of the flag)
The disjunction with instance->force_enable_shader_atomics is kept as
a documented kill-switch even though the compiler folds it away —
it leaves the DRI option pan_force_enable_shader_atomics semantically
wired for future rebases or downstream debugging.
Patch reviewed via 2nd-model pass (per bugfix-process step 4):
recommended keeping the disjunction (applied), Bifrost-only-vs-unconditional
left unconditional to match upstream (applied), pre-ship CTS subset
(applied with results above).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Both PKGBUILDs referenced url=https://github.com/marfrit/panvk-bifrost,
which was a hallucinated URL — no such repo existed. The campaign's
real source-of-truth home was just created at
https://git.reauktion.de/marfrit/panvk-bifrost (mfritsche, 2026-05-23).
Point both PKGBUILDs at the real URL so `pacman -Si` and any consumer
reading package metadata follows a working link.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
H264QpelContext.put_h264_qpel_pixels_tab[1][2] (8x8 luma horizontal
half-pel, 6-tap "put" — the canonical representative of the H.264
luma motion-compensation family) now dispatches through
daedalus_recipe_dispatch_h264_qpel_mc20 instead of
ff_put_h264_qpel8_mc20_neon.
Cycle 9 of the daedalus-v4l2#11 step 2 substitution arc; closes the
4-cycle libavcodec.so substitution sequence:
cycle 6 (PR #76) H.264 IDCT 4x4 done
cycle 7 (PR #85) H.264 IDCT 8x8 done
cycle 8 (PR #86) H.264 luma-v deblock done
cycle 9 (this) H.264 qpel mc20
Bumps daedalus-fourier pin d87239d → 209a421 (PR #2 — public API
gains daedalus_recipe_dispatch_h264_qpel_mc20 +
DAEDALUS_KERNEL_H264_QPEL_MC20).
Verdict per docs/k9_h264qpel_mc20.md: CPU NEON. Per-block 7.6 ns at
131 Mblock/s gives 135× margin over 30 fps 1080p; QPU dispatch floor
at ~250 ns makes any V3D shader strictly worse. Substitution is
plumbing-only — same daedalus_ctx_create_no_qpu pthread_once shape
the cycles 6/7/8 shims already own (kept SEPARATE from the H264DSP
shim's ctx because H264QPEL is its own libavcodec Makefile module
and link order does not guarantee a single .o owns the ctx symbol;
one extra ~µs init per process, paid lazily on first MC call).
Other H.264 luma MC variants (mc02, mc11, mc22 etc.) and the 16x16
size tier stay on the in-tree NEON .S code per the cycle-9 phase-1
rationale (mc20 8x8 is representative; remaining variants would
multiply recipe-lookup overhead without changing the substrate
verdict).
Bit-exact against ff_put_h264_qpel8_mc20_neon (daedalus-fourier
cycle 9 green; 10000/10000 random blocks bit-exact, M3 = 131 Mblock/s).
No SONAME change, no Depends change. PKGREL 9 → 10.
Refs reauktion/daedalus-v4l2#11 — substitution arc step 2 cycle 9.
Picks up reauktion/daedalus-v4l2 PR #20 (closes#19): wire-protocol
cap DAEDALUS_PROTO_MAX_PAYLOAD raised from 64 KiB to 1 MiB.
DAEDALUS_MAX_BITSTREAM follows; daedalus_fill_output_fmt now reports
OUTPUT_MPLANE sizeimage = ~1 MiB.
Fixes the Firefox YouTube avc1 SW-fallback observed on higgs when
any H.264 slice exceeded 64 KiB (routine on 720p+ streams).
libva-v4l2-request-fourier's S_FMT-driven OUTPUT-pool resize was
clamping back to 65484 and Firefox lost the slice; now the kernel
honours the larger sizeimage.
Both packages bumped to 0.1.0+r45+g872eec5-1:
- daedalus-v4l2 (daemon): r43 -> r45. Daemon-side allocations
are dynamic, so the only growth is one ~1 MiB read buffer per
daemon process at startup.
- daedalus-v4l2-dkms (kernel module): r33 -> r45. Skips the
daemon-only bumps r37/r39/r41/r43 (no kernel/include change in
that range) and lands the PROTO_MAX_PAYLOAD bump.
LOCK-STEP INSTALL REQUIRED: effective cap is min(kernel, daemon).
A stale kernel with a new daemon (or vice versa) still rejects
>64 KiB payloads. apt/pacman should pick both up in one
transaction since they share the same upstream pin.
Wire-protocol value-only change in include/daedalus_v4l2_proto.h;
struct layout unchanged. DAEDALUS_PROTO_VERSION stays at 0.
Picks up reauktion/daedalus-v4l2 PR #18 (closes#17): daemon drops
degenerate (<4 byte) bitstreams at REQ_DECODE entry instead of
letting avcodec_send_packet emit AVERROR_INVALIDDATA, replies
RESP_FRAME NO_FRAME so libva's V4L2 surface pool stays alive.
Fixes the Firefox YouTube avc1 pause→resume regression observed on
higgs: libva-v4l2-request-fourier flushes a 3-byte stub into
OUTPUT_MPLANE at the pause boundary; the old daemon path turned
that into a decode failure, Firefox marked H.264-via-VAAPI as
broken for the session, and routed every subsequent frame to
libmozavcodec SW. After this bump the daemon logs 'tiny bitstream
3 bytes — dropping as no-op' and the next real REQ_DECODE
proceeds normally.
Wire protocol unchanged. daedalus-v4l2-dkms bump not needed.
FFmpeg 8.x dropped the H.264 decoder's low_delay code path —
AV_CODEC_FLAG_LOW_DELAY no longer prevents h264_select_output_frame
from running the display-order DPB output queue. The daedalus-v4l2
daemon's `ctx->flags |= AV_CODEC_FLAG_LOW_DELAY` at
daemon/src/decoder.c:202 has been a silent no-op since the SONAME
61→62 jump landed in reauktion/daedalus-v4l2 PR #16; on Firefox
YouTube this re-introduced the 2-1-4-3 B-frame pair-swap that PR
#12's daemon flag was supposed to prevent.
Fix lives in libavcodec, not the daemon: restore the documented
LOW_DELAY semantics so the daemon (and any other V4L2-stateless-
style consumer) keeps the one-frame-per-send_packet decode-order
output contract it already declares.
## Patch
0006-h264-restore-low-delay.patch touches libavcodec/h264_slice.c:
- h264_select_output_frame: early-exit when LOW_DELAY is set.
Emit the just-decoded picture as next_output_pic, mirror the
corruption / recovery-point tracking the main path performs,
skip delayed_pic[] / POC reorder machinery entirely.
- h264_field_start: suppress the SPS-driven
`has_b_frames = sps->num_reorder_frames` clobber when LOW_DELAY
is set. Without this the per-slice bitstream_restriction_flag
re-pickup would reintroduce a nonzero reorder buffer mid-stream
even after the daemon set has_b_frames=0 at avcodec_open2.
## Why not daemon-side
A daemon SPS-rewrite (`num_reorder_frames=0`) was considered but
rejected: it works only for the daemon's reconstructed SPS NAL,
not for any in-band SPS the daemon dlopens libavformat to parse
in other code paths. Restoring documented FFmpeg flag semantics
is the smaller, more durable change and keeps the daemon
interface stable.
## Packaging
- PKGREL/pkgrel bump to 9.
- No new build-deps, no Depends change.
- Substitution arc cycles 6/7/8 unchanged.
## Refs
- reauktion/daedalus-v4l2#11 / #12 (LOW_DELAY half-measure on
daemon side, originally landed against FFmpeg 7.x).
- daemon/src/decoder.c:202 (`ctx->flags |= AV_CODEC_FLAG_LOW_DELAY`
for H.264 only — unchanged, but now actually has effect again).
Cycle 8 of the libavcodec.so substitution arc (reauktion/daedalus-v4l2#11
step 2). H264DSPContext.v_loop_filter_luma — non-intra bS<4 vertical
luma deblock, called per macroblock-row edge from the slice deblock
loop in libavcodec/h264_loopfilter.c — now dispatches through
daedalus_recipe_dispatch_h264_deblock_luma_v instead of
ff_h264_v_loop_filter_luma_neon.
## What
- Add 0005-h264-deblock-luma-v-daedalus-fourier.patch (in both arch/
and debian/ ffmpeg-v4l2-request-fourier/). Extends
libavcodec/aarch64/h264_idct_daedalus.c with
ff_h264_v_loop_filter_luma_daedalus (constructs a
daedalus_h264_deblock_meta from FFmpeg's (alpha, beta, tc0[4]) and
calls daedalus_recipe_dispatch_h264_deblock_luma_v with n_edges=1).
Patches libavcodec/aarch64/h264dsp_init_aarch64.c to wire
c->v_loop_filter_luma to the new shim.
- arch/PKGBUILD + debian/build-deb.sh: append patch + bump pkgrel/PKGREL
to 8.
- No new build-deps, no Depends change, no daedalus-fourier rev — the
d87239d pin already exposes daedalus_recipe_dispatch_h264_deblock_luma_v.
## Why
Cycle 8 is marked "CPU primary; QPU opportunistic" in the daedalus-
fourier API docstring. Per the hybrid substrate philosophy
("if there's a coprocessor, use it") we eventually want the QPU
opportunism active here. But the libavcodec.so context is
process-global and shared with cycles 6/7 via pthread_once, and it
uses daedalus_ctx_create_no_qpu deliberately to avoid implicit
Vulkan init in arbitrary host processes (Firefox content, mpv-fourier,
ffmpeg-fourier CLI, ...). Switching to daedalus_ctx_create here
without a feature flag would be a footgun.
So cycle 8 lands as plumbing-only NEON-by-recipe substitution for
now; opportunistic QPU enablement is a separate follow-up that adds
a DAEDALUS_FOURIER_ENABLE_QPU env var or equivalent.
## Scope NOT covered
- Intra (bS=4) loop filter c->v_loop_filter_luma_intra — daedalus's
daedalus_h264_deblock_meta only covers the non-intra path.
- Horizontal-edge variant c->h_loop_filter_luma — separate kernel
(not yet in daedalus-fourier API).
- Chroma loop filters — separate kernels.
- Bulk batching — single-edge dispatch wastes the kernel's n_edges>1
amortization. Same caveat as cycles 6/7; follow-up.
- QPU opportunism — see "Why" above.
## SONAME
Unchanged. libavcodec.so.62 / libavformat.so.62 / libavutil.so.60.
## Refs
- reauktion/daedalus-v4l2 issue #11: reauktion/daedalus-v4l2#11
- marfrit-packages PR #76 (cycle 6 IDCT 4×4)
- marfrit-packages PR #85 (cycle 7 IDCT 8×8)
- marfrit/daedalus-fourier cycle 8 close (deblock luma-v NEON green)
Cycle 7 of the libavcodec.so substitution arc (reauktion/daedalus-v4l2#11
step 2). H264DSPContext.idct8_add — called per 8×8 block from the
High-profile intra-8×8-DCT decode path in libavcodec/h264_mb.c — now
dispatches through daedalus_recipe_dispatch_h264_idct8 instead of
ff_h264_idct8_add_neon.
## What
- Add 0004-h264-idct8-daedalus-fourier.patch (in both arch/ and debian/
ffmpeg-v4l2-request-fourier/). Extends libavcodec/aarch64/
h264_idct_daedalus.c (introduced by 0003) with ff_h264_idct8_add_daedalus
and a daedalus_recipe_dispatch_h264_idct8 call; patches
libavcodec/aarch64/h264dsp_init_aarch64.c to wire c->idct8_add to
the new shim.
- arch/PKGBUILD + debian/build-deb.sh: append the new patch to the
apply list; bump pkgrel/PKGREL to 7.
- No new build-deps, no Depends change, no daedalus-fourier rev — the
d87239d pin already exposes daedalus_recipe_dispatch_h264_idct8.
## Why
The recipe layer picks the substrate; for cycle 7 (H.264 IDCT 8×8)
the recipe is CPU NEON, so this is effectively a NEON-to-NEON
substitution layered on top of cycle 6. Production validation of
cycle 6 on higgs Firefox YouTube: 3040 frames decoded cleanly,
avg_decode_us=3388 (no regression vs the pre-substitution ~4 ms
baseline). Cycle 7 inherits the same shim's pthread_once context.
Bit-exact against ff_h264_idct8_add_neon (daedalus-fourier cycle 7
green; FFmpeg 8×8 block storage block[r + 8*c] matches daedalus
column-major convention).
## Scope NOT covered (deferred)
- Bulk c->idct8_add4 (inter 8×8-DCT macroblocks) stays on the
in-tree NEON .S code; batched substitution with n_blocks>1 lands
later alongside the cycle-6 bulk-paths work.
- High-bit-depth (10-bit) path untouched.
- Cycles 8/9 — separate PRs.
## SONAME
Unchanged. libavcodec.so.62 / libavformat.so.62 / libavutil.so.60.
## Refs
- reauktion/daedalus-v4l2 issue #11 (substitution arc): reauktion/daedalus-v4l2#11
- marfrit-packages PR #76 (cycle 6 IDCT 4×4)
- marfrit-packages PR #78 (libxml2 ABI-skew workaround)
- marfrit/daedalus-fourier cycle 7 close (H.264 IDCT 8×8 NEON green)
The original 0005 patch was generated from the pre-Phase-5-review source
snapshot (phase5_review_input_2026-05-21.tgz), missing the four
load-bearing review fixes that landed in the post-review snapshot:
- probe_hantro gate on KHR_video_* extension advertisement
- per-session ts_counter (was process-global static)
- panvk_v4l2_session_finish full unwind (munmap + STREAMOFF + REQBUFS=0)
- MIN2(rb.count, 18) clamp on num_*_buffers
Run #162 (job 17032) failed in prepare() because the PKGBUILD sanity
check 'grep -q "KHR_video_queue = PAN_ARCH < 9 && panvk_v4l2_probe_hantro()"'
didn't match the actual patched output (which still had the pre-review
'KHR_video_queue = PAN_ARCH < 9,').
This patch (regenerated from phase5_post_review_2026-05-21.tgz) carries
all four review fixes. Validated locally: vanilla mesa-26.0.6 + r1..r4 +
this patch reproduces prepare()-OK byte-for-byte.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The original PR #79 used symlinks for 0001..0004 patches (pointing into
../mesa-panvk-bifrost/) to avoid drift between siblings. CI's
"cp -r arch/mesa-panvk-bifrost-video /tmp/build-..." preserves the
symlinks, but the destination /tmp/build-... has no sibling dir to
resolve them against, so makepkg errors with:
==> ERROR: 0001-panvk-expose-robustness2-nullDescriptor-bifrost.patch
was not found in the build directory and is not a URL.
Each Arch PKGBUILD owns its source files per convention; the
duplication risk is low because r1..r4 are closed-release patches.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
PR #79 (6ee8f2748, mesa-panvk-bifrost-video) added a second `run:`
mapping key on the next line of the same step:
- name: wipe secrets
if: always()
run: rm -f /root/repo_pass /root/.ssh/id_ed25519
run: rm -f /root/.ssh/id_ed25519_hertz ← duplicate `run:` key
YAML doesn't allow two mappings with the same key in one node, so
Gitea's workflow parser rejected the entire file:
actions/workflows.go:124:DetectWorkflows() [W]
ignore invalid workflow "build.yml": yaml: unmarshal errors:
line 1423: mapping key "run" already defined at line 1422
Result: every push to main since 6ee8f2748 (2026-05-21 23:14 CEST)
silently failed to enqueue ANY action run. PR #80's "re-trigger by
README touch" had no chance — workflow file was invalid before #80
even existed. Runs #161-163 do not exist; #160 (pre-#79) is the
last successful enqueue.
Fix: merge the two single-line `run:` invocations into one literal
block. Functionally identical, YAML-valid.
Post-merge: workflow file becomes valid again, new push to main
triggers a fresh build run covering the backlog (#79's
mesa-panvk-bifrost-video build that #80 wanted re-triggered).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The merge commit for PR #79 (e7cc22e42) did not auto-fire the
Gitea Actions workflow despite touching paths matched by the
build.yml filter (arch/** + .gitea/workflows/**). No run row
exists between #160 (PR #78 merge) and now. This README touch
is a no-op content change to force a fresh workflow_dispatch
through the standard push trigger.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The Gitea debian-aarch64 runner has been upgraded past Debian trixie
and now ships libxml2 ≥ 2.14 (SONAME 16) while higgs (and any other
trixie target) still has libxml2 2.12 (SONAME 2). -5 built cleanly,
but on higgs the daedalus-v4l2 daemon's dlopen of libavformat.so.62
fails:
dlopen(libavformat.so.62): libxml2.so.16:
cannot open shared object file: No such file or directory
Drop --enable-libxml2 from the Debian configure invocation; remove
the libxml2 entry from Depends; remove libxml2-dev from the CI
build-deps. FFmpeg's libxml2-backed DASH demuxer is unused on the
Fourier fleet — daedalus-v4l2 daemon feeds AVPackets straight to
avcodec_send_packet (no demux); mpv-fourier uses ytdlp + mpv's own
stream code; firefox-fourier uses gecko-media's DASH demux.
Bumps PKGREL 5 → 6. No source code or substitution-patch change.
Mirrors the libva trixie/runner ABI-skew workaround pattern
(marfrit-packages PR #62).
Arch PKGBUILD unaffected — Arch runner + Arch consumers both
rolling, libxml2 SONAMEs match.
After this lands, re-deploy on higgs via:
sudo apt update && sudo apt install -y ffmpeg-v4l2-request-fourier
sudo systemctl restart daedalus-v4l2
panvk-bifrost-video campaign close. Phase 4 byte-exact validated
2026-05-21 on RK3566/PineTab2 (Mali-G52 r1 MC1 + hantro VPU): 48/48
unique BBB display frames decoded by this driver are byte-identical
to ffmpeg+libva-v4l2-request-fourier on the same hantro hardware
(frame 42 Y md5 = 54b9b396e6cd377256eb4bce0efc0bed both ways).
Phase 5 second-model review passed; load-bearing findings applied.
Co-installs at /usr/lib/panvk-bifrost-video/ parallel to the r4
sibling at /usr/lib/panvk-bifrost/; opt-in via VK_ICD_FILENAMES.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
marfrit
claude-noether
claude-noether