280 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
marfrit	5d97cf15d6	Merge pull request 'chromium-fourier: bump to 148.0.7778.178, add Debian recipe' (#93) from claude-noether/marfrit-packages:noether/chromium-fourier-148 into main ... Reviewed-on: #93	2026-05-24 19:46:13 +00:00
marfrit	58f67d4b2c	chromium-fourier: bump to 148.0.7778.178, add Debian recipe ... 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>	2026-05-24 09:45:30 +02:00
marfrit	685f85c22e	Merge pull request 'mesa-panvk-bifrost: r4 -> r5 — advertise fragmentStoresAndAtomics on Bifrost (closes panvk-bifrost#2)' (#92) from claude-noether/marfrit-packages:noether/mesa-panvk-bifrost-r5 into main ... Reviewed-on: #92	2026-05-23 12:19:10 +00:00
marfrit	6896853544	mesa-panvk-bifrost: r4 -> r5 — advertise fragmentStoresAndAtomics on Bifrost ... 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>	2026-05-23 14:04:44 +02:00
marfrit	fd56eca3cb	Merge pull request 'mesa-panvk-bifrost{,-video}: fix url= to real Gitea repo' (#91) from claude-noether/marfrit-packages:noether/panvk-bifrost-url-fix into main ... Reviewed-on: #91	2026-05-23 03:18:37 +00:00
marfrit	91022b390e	mesa-panvk-bifrost{,-video}: fix url= to real Gitea repo ... 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>	2026-05-23 05:17:41 +02:00
marfrit	b736dd0529	Merge pull request 'ffmpeg-v4l2-request-fourier: substitute H.264 qpel mc20 → daedalus-fourier' (#90) from claude-noether/marfrit-packages:noether/ffmpeg-fourier-qpel-mc20-daedalus into main ... Reviewed-on: #90	2026-05-23 01:34:04 +00:00
claude-noether	0bfc4ab03e	ffmpeg-v4l2-request-fourier: substitute H.264 qpel mc20 → daedalus-fourier ... 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.	2026-05-23 03:32:29 +02:00
marfrit	8729c2db92	Merge pull request 'daedalus-v4l2 + daedalus-v4l2-dkms: bump to 872eec5 — PROTO_MAX_PAYLOAD 1 MiB (#20)' (#89) from claude-noether/marfrit-packages:noether/daedalus-bump-872eec5-1mib-payload into main ... Reviewed-on: #89	2026-05-22 18:52:53 +00:00
marfrit	d449ec1073	daedalus-v4l2 + daedalus-v4l2-dkms: bump to 872eec5 — PROTO_MAX_PAYLOAD 1 MiB (#20) ... 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.	2026-05-22 20:50:04 +02:00
marfrit	9d30c34be9	Merge pull request 'daedalus-v4l2: 6e6dfa1 -> 1d8f5af — pause-time tiny-bitstream filter (#18)' (#88) from claude-noether/marfrit-packages:noether/daedalus-bump-1d8f5af-pause-filter into main ... Reviewed-on: #88	2026-05-22 16:20:14 +00:00
marfrit	1ca18ac130	daedalus-v4l2: 6e6dfa1 -> 1d8f5af — pause-time tiny-bitstream filter (#18) ... 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.	2026-05-22 18:16:33 +02:00
marfrit	cf9eef6cfa	Merge pull request 'ffmpeg-v4l2-request-fourier: restore AV_CODEC_FLAG_LOW_DELAY in H.264 decoder' (#87) from claude-noether/marfrit-packages:noether/ffmpeg-fourier-restore-low-delay into main ... Reviewed-on: #87	2026-05-22 14:27:43 +00:00
marfrit	5c69460722	ffmpeg-v4l2-request-fourier: restore AV_CODEC_FLAG_LOW_DELAY in H.264 decoder ... 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).	2026-05-22 14:20:37 +02:00
marfrit	d11a52405d	Merge pull request 'ffmpeg-v4l2-request-fourier: substitute H.264 luma-v deblock → daedalus-fourier' (#86) from claude-noether/marfrit-packages:noether/ffmpeg-fourier-deblock-luma-v-daedalus into main ... Reviewed-on: #86	2026-05-22 10:29:09 +00:00
marfrit	29e0852d11	ffmpeg-v4l2-request-fourier: substitute H.264 luma-v deblock → daedalus-fourier ... 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)	2026-05-22 12:17:14 +02:00
marfrit	510a31622c	Merge pull request 'ffmpeg-v4l2-request-fourier: substitute H.264 IDCT 8×8 → daedalus-fourier' (#85) from claude-noether/marfrit-packages:noether/ffmpeg-fourier-idct8-daedalus into main ... Reviewed-on: #85	2026-05-22 08:32:15 +00:00
marfrit	db9ae16da9	Merge pull request 'mesa-panvk-bifrost-video: regenerate 0005 patch from POST-review snapshot' (#84) from claude-noether/marfrit-packages:noether/mesa-panvk-bifrost-video-retrigger into main ... Reviewed-on: #84	2026-05-22 08:20:34 +00:00
marfrit	493c762967	ffmpeg-v4l2-request-fourier: substitute H.264 IDCT 8×8 → daedalus-fourier ... 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)	2026-05-22 10:20:27 +02:00
marfrit	7ecbcb3c1b	mesa-panvk-bifrost-video: regenerate 0005 patch from POST-review snapshot ... 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>	2026-05-22 10:18:11 +02:00
marfrit	360e8eb6bf	Merge pull request 'mesa-panvk-bifrost-video: r1-r4 patches as real files (symlinks broke CI)' (#83) from claude-noether/marfrit-packages:noether/mesa-panvk-bifrost-video-retrigger into main ... Reviewed-on: #83	2026-05-22 07:55:59 +00:00
marfrit	4db64917bc	mesa-panvk-bifrost-video: r1-r4 patches as real files (symlinks broke CI) ... 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>	2026-05-22 09:49:59 +02:00
marfrit	6288536223	Merge pull request 'ci: fix duplicate run: key in build.yml wipe-secrets step (unblocks all builds since 2026-05-21)' (#82) from claude-noether/marfrit-packages:noether/fix-build-yaml-duplicate-run into main ... Reviewed-on: #82	2026-05-22 07:30:37 +00:00
claude-noether	09d8813507	ci: fix duplicate run: key in build.yml wipe-secrets step ... 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>	2026-05-22 09:15:18 +02:00
marfrit	8a3186b53c	Merge pull request 'mesa-panvk-bifrost-video: re-trigger Actions for PR #79' (#80) from claude-noether/marfrit-packages:noether/mesa-panvk-bifrost-video-retrigger into main ... Reviewed-on: #80	2026-05-22 06:32:42 +00:00
marfrit	b81e2251c2	mesa-panvk-bifrost-video: re-trigger Actions for PR #79 ... 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>	2026-05-22 07:51:01 +02:00
marfrit	e7cc22e42d	Merge pull request 'mesa-panvk-bifrost-video: sibling package adding VK_KHR_video_decode_h264' (#79) from claude-noether/marfrit-packages:noether/mesa-panvk-bifrost-video-phase8 into main ... Reviewed-on: #79	2026-05-21 21:33:53 +00:00
marfrit	62b6b0a700	Merge pull request 'ffmpeg-v4l2-request-fourier (debian): drop --enable-libxml2 (runner SONAME skew)' (#78) from claude-noether/marfrit-packages:noether/ffmpeg-fourier-drop-libxml2 into main ... Reviewed-on: #78	2026-05-21 21:24:07 +00:00
marfrit	a8f4a70887	ffmpeg-v4l2-request-fourier (debian): drop --enable-libxml2 (runner SONAME skew) ... 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	2026-05-21 23:18:00 +02:00
marfrit	6ee8f2748e	mesa-panvk-bifrost-video: sibling package adding VK_KHR_video_decode_h264 ... 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>	2026-05-21 23:14:01 +02:00
marfrit	711a921e66	Merge pull request 'ffmpeg-v4l2-request-fourier: PKGREL 3 → 5 (force rebuild past orphan -4 .deb)' (#77) from claude-noether/marfrit-packages:noether/ffmpeg-fourier-debian-pkgrel-5 into main ... Reviewed-on: #77	2026-05-21 20:36:15 +00:00
marfrit	9bf97fdb49	ffmpeg-v4l2-request-fourier: PKGREL 3 → 5 (force rebuild past orphan -4 .deb) ... PR #76 (H.264 IDCT 4×4 daedalus-fourier substitution) was merged but the resulting .deb was not actually built: an orphan ffmpeg-v4l2-request-fourier_8.1+rfourier+gb57fbbe-4_arm64.deb (dated 2026-05-19, no matching source commit in main) sat in the apt pool. .gitea/scripts/check-already-published.sh's debian branch compares `dpkg --compare-versions $pool_ver ge $source_full` — pool -4 ≥ source -3, so CI's skip-check emitted skip=1 and short-circuited the build. The ffmpeg-v4l2-request-debian Action reported success without actually publishing. Bump source PKGREL past -4 so the next CI run sees source >= pool and proceeds to build + publish. No source code change beyond PKGREL + changelog. Arch side unaffected (its skip-check is exact-URL-match, not pool-head-ge).	2026-05-21 22:17:00 +02:00
marfrit	a536e20218	Merge pull request 'ffmpeg-v4l2-request-fourier: substitute H.264 IDCT 4×4 → daedalus-fourier' (#76) from claude-noether/marfrit-packages:noether/ffmpeg-fourier-idct4-daedalus into main ... Reviewed-on: #76	2026-05-21 19:57:31 +00:00
marfrit	a1dba5f630	Merge remote-tracking branch 'origin/main' into noether/ffmpeg-fourier-idct4-daedalus	2026-05-21 21:56:41 +02:00
marfrit	88a65cb6d0	CI: add cmake / ninja-build / libvulkan-dev / glslang-tools to ffmpeg-debian deps ... The ffmpeg-v4l2-request-debian job now needs to build daedalus-fourier into a temp prefix before configuring FFmpeg (substitution patch 0003-h264-idct4-daedalus-fourier.patch links libdaedalus_core.a into libavcodec.so). Mirror the build-deps the daedalus-v4l2-debian job already declared for the same reason. No-op on Arch — makepkg --syncdeps auto-installs cmake/ninja/ vulkan-headers from the PKGBUILD makedepends.	2026-05-21 21:47:48 +02:00
marfrit	e641d679d3	ffmpeg-v4l2-request-fourier: substitute H.264 IDCT 4×4 → daedalus-fourier ... First cycle of the libavcodec.so substitution arc (reauktion/daedalus-v4l2#11 step 2). H264DSPContext.idct_add — called per 4×4 block from the intra-4×4 decode path in libavcodec/h264_mb.c — now dispatches through daedalus_recipe_dispatch_h264_idct4 instead of ff_h264_idct_add_neon. ## What - Add 0003-h264-idct4-daedalus-fourier.patch (in both arch/ and debian/ ffmpeg-v4l2-request-fourier/). Creates libavcodec/aarch64/h264_idct_daedalus.c (ff_h264_idct_add_daedalus shim + lazy pthread_once context init via daedalus_ctx_create_no_qpu), patches libavcodec/aarch64/h264dsp_init_aarch64.c to wire c->idct_add to the shim, adds the new .o to libavcodec/aarch64/Makefile. - arch/PKGBUILD + debian/build-deb.sh: fetch + build daedalus-fourier (pinned at d87239d — lockstep with the daedalus-v4l2 daemon's inline build) with -DCMAKE_POSITION_INDEPENDENT_CODE=ON into a per-build temp prefix, then pass --extra-cflags=-I.../include --extra-ldflags=-L.../lib --extra-libs="-ldaedalus_core -lvulkan -lpthread" to FFmpeg configure. daedalus_core.a is static-linked into libavcodec.so.62. - debian/control Depends gains libvulkan1 (daedalus_core PUBLIC-links Vulkan::Vulkan for the queryable QPU substrate; the no-QPU constructor still works at runtime but the loader needs libvulkan.so.1 present to dlopen libavcodec.so.62). - arch/PKGBUILD depends gains vulkan-icd-loader, makedepends gains cmake / ninja / vulkan-headers. ## Why The recipe layer picks the substrate; for cycle 6 (H.264 IDCT 4×4) the recipe is CPU NEON, so this is effectively a NEON-to-NEON substitution with one extra dispatch call and recipe-table lookup. The point of this first cycle isn't perf wins — it's plumbing. Once the path is wired and stable, follow-up patches batch through the bulk paths (idct_add16 / idct_add16intra / idct_add8) and stack cycles 7/8/9 (IDCT 8×8, luma-v deblock, qpel mc20). Bit-exact against ff_h264_idct_add_neon (daedalus-fourier cycle 6 green; FFmpeg's 4×4 block storage matches daedalus's column-major convention). ## Scope NOT covered - Bulk paths (idct_add16 / idct_add16intra / idct_add8) — most IDCT 4×4 calls in real H.264 streams go through these, not the per- block c->idct_add path; intra-4×4-only macroblocks are a minority. Batched substitution lands in a follow-up. - High-bit-depth (10-bit) path — not touched; 8-bit only. - Cycles 7/8/9 — separate PRs. ## SONAME Unchanged. libavcodec.so.62 / libavformat.so.62 / libavutil.so.60. No daedalus-v4l2-dkms or daedalus-v4l2 bump required. ## Refs - reauktion/daedalus-v4l2 issue #11 (substitution arc): reauktion/daedalus-v4l2#11 - marfrit/daedalus-fourier cycle 6 close (H.264 IDCT 4×4 NEON green)	2026-05-21 21:44:35 +02:00
marfrit	877238bd1b	Merge pull request 'daedalus-v4l2: 3bc0da1 -> 6e6dfa1 — dlopen Kwiboo soname 62 + CI build-deps swap' (#75) from claude-noether/marfrit-packages:noether/daedalus-bump-6e6dfa1-soname62 into main ... Reviewed-on: #75	2026-05-21 19:26:39 +00:00
claude-noether	27617e4cb0	daedalus-v4l2: 3bc0da1 -> 6e6dfa1 — dlopen Kwiboo soname 62 (#16)	2026-05-21 21:24:03 +02:00
marfrit	a2daab1b28	Merge pull request 'daedalus-v4l2: 77e14e5 -> 3bc0da1 — decode_us + periodic stats' (#74) from claude-noether/marfrit-packages:noether/daedalus-bump-3bc0da1 into main ... Reviewed-on: #74	2026-05-21 18:50:46 +00:00
claude-noether	9146e83710	daedalus-v4l2: 77e14e5 -> 3bc0da1 — decode_us + periodic stats (#15)	2026-05-21 20:29:07 +02:00
marfrit	abf8fb3077	Merge pull request 'ci: add libvulkan-dev + glslang-tools for daedalus-fourier build dep' (#73) from claude-noether/marfrit-packages:noether/ci-fourier-build-deps into main ... Reviewed-on: #73	2026-05-21 18:05:59 +00:00
claude-noether	1414dfeac2	.gitea/workflows: add libvulkan-dev + glslang-tools to daedalus-v4l2 Debian build deps ... The daedalus-v4l2 build-deb.sh (post marfrit-packages#72) now fetches + cmake-builds daedalus-fourier into a per-build temp prefix before building the daemon, so the static-archive can be linked in. daedalus-fourier's CMakeLists requires Vulkan headers and glslangValidator (for SPIR-V compilation of the .comp compute shaders). Without them the configure step on the debian-aarch64 runner fails with: CMake Error at FindPackageHandleStandardArgs.cmake:233 (message): Could NOT find Vulkan (missing: Vulkan_LIBRARY Vulkan_INCLUDE_DIR) (Observed on Gitea Actions run 1056.) Add `libvulkan-dev` and `glslang-tools` to the apt-get install line so the in-build daedalus-fourier compile succeeds and the daemon can link.	2026-05-21 19:58:19 +02:00
marfrit	41c1e0b6b9	Merge pull request 'daedalus-v4l2: 5d8b436 -> 77e14e5 — #12 (LOW_DELAY) + #13 (daedalus-fourier linkage)' (#72) from claude-noether/marfrit-packages:noether/daedalus-bump-77e14e5-with-fourier into main ... Reviewed-on: #72	2026-05-21 17:15:12 +00:00
claude-noether	c9a4b82f2c	daedalus-v4l2: 5d8b436 -> 77e14e5 — picks up #12 (LOW_DELAY) + #13 (daedalus-fourier linkage) ... Daemon-only bump (no daedalus-v4l2-dkms change needed; PROTO_VERSION stays at 0). #12 (LOW_DELAY half-measure): daemon sets AV_CODEC_FLAG_LOW_DELAY on the H.264 AVCodecContext so libavcodec emits frames in decode order ~99% of the time (a few stragglers at GOP boundaries when the stream's SPS num_reorder_frames overrides the flag). Visible improvement vs the 2-1-4-3 pair-swap on Firefox + mpv playback; not the permanent fix — see daedalus-v4l2#11 for the architectural plan to substitute daedalus-fourier kernels for libavcodec's pixel math one cycle at a time. #13 (daedalus-fourier linkage): daemon now pkg-config-links against the daedalus-fourier kernel library (marfrit/daedalus-fourier) and logs substrate availability at startup. No kernels dispatched yet — this is the build-time foundation for the substitution work. build-deb.sh updated to fetch + build + install daedalus-fourier (pinned at d87239d, marfrit/daedalus-fourier PR #1) into a per- build temp prefix before invoking the daemon's cmake, exposing it via PKG_CONFIG_PATH. Static-linked, so the resulting .deb has no new runtime deps. Requires libvulkan-dev + glslang-tools on the CI runner. Arch PKGBUILD bumped to the same upstream commit but Arch packaging for daedalus-fourier itself is a follow-up; until that lands the Arch build expects daedalus-fourier installed by the user (AUR-style). Debian-side is end-to-end self-contained via build-deb.sh. Refs: * reauktion/daedalus-v4l2#12 * reauktion/daedalus-v4l2#13 * reauktion/daedalus-v4l2#11 * marfrit/daedalus-fourier#1	2026-05-21 18:39:22 +02:00
marfrit	736b6da176	Merge pull request 'daedalus-v4l2{,-dkms}: 79256dc/6ffe92b -> 5d8b436 — revert parking design' (#71) from claude-noether/marfrit-packages:noether/daedalus-revert-bump-5d8b436 into main ... Reviewed-on: #71	2026-05-21 14:54:18 +00:00
claude-noether	34972ae9c1	daedalus-v4l2{,-dkms}: 79256dc/6ffe92b -> 5d8b436 — revert parking design ... Lock-step downgrade of both packages to the revert tip of daedalus-v4l2 (PR #10 closed PRs #7 + #8). After 0.1.0+r28+g79256dc-1 / 0.1.0+r30+g6ffe92b-1 landed in production, mpv (--hwdec=vaapi-copy) failed pre-playing with "Unable to dequeue buffer: Resource temporarily unavailable" because the daemon parked CAPTURE buffers waiting for libavcodec's display-order reorder, violating libva's V4L2 stateless 1:1 contract. See daedalus-v4l2#9 for the diagnostic, #10 for the revert PR. DAEDALUS_PROTO_VERSION drops 1 → 0; install both .debs in the same apt transaction. Userspace ABI returns to the f0d4186-equivalent behaviour, plus PR #4 (cosmetic H.264 menu controls). The daedalus-v4l2-dkms #64 multi-kernel postinst behaviour stays in build-deb.sh. Visible regression: H.264 B-frame streams in Firefox return to the "2 1 4 3 6 5" pair-swap visual. Proper fix (concurrent in-flight requests in daemon + display-order reorder moved into libva-v4l2- request-fourier) tracked at daedalus-v4l2#11. Refs: * reauktion/daedalus-v4l2#9 * reauktion/daedalus-v4l2#10 (merged) * reauktion/daedalus-v4l2#11	2026-05-21 15:42:03 +02:00
marfrit	a9f1b833b9	Merge pull request 'mesa-panvk-bifrost: r3 -> r4 — iter17 XFB primitive decomposition' (#70) from claude-noether/marfrit-packages:noether/mesa-panvk-bifrost-r4-iter17-xfb-decomp into main ... Reviewed-on: #70	2026-05-21 12:18:23 +00:00
marfrit	83e8eca56d	mesa-panvk-bifrost: r3 -> r4 — iter17 XFB primitive decomposition ... iter17 closes the 162 winding_* CTS failures from iter15's baseline by replacing the upstream pan_nir_lower_xfb call with a panvk-specific NIR pass (panvk_per_arch(nir_lower_xfb)) that handles per-primitive decomposition for non-LIST topologies (LINE_STRIP, TRIANGLE_STRIP, TRIANGLE_FAN, and the four _WITH_ADJACENCY variants). Topology + per-instance output vertex count are threaded as new sysvals (vs.xfb_topology + vs.xfb_output_count) so the NIR pass can dispatch per-topology at runtime without compiling 7+ shader variants. dEQP-VK.transform_feedback.simple.* result (133596 cases total): iter15 baseline -> iter17 Pass: 796 958 (+162) Fail: 243 81 (-162; resume_* by-design only) NotSupported: 132551 132551 Fatal-skip: 6 6 Pass rate of runnable: 76.2% -> 91.7% (+15.5pp) 100% of the iter15 winding-fail cluster closed. The remaining 81 fails are all resume_* (pause/resume XFB, by design — we advertise transformFeedbackDraw=false). Second-model review (janet) produced 3 findings; Findings 1+2 were already fixed in the in-tree applied state (stale applied_state/ snapshot read by reviewer), Finding 3 (degenerate N underflow on N<2) addressed by gating non-LIST emission on `output_count > 0` predicate. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-21 14:07:00 +02:00
marfrit	1c8c186681	Merge pull request 'daedalus-v4l2-dkms: 79256dc -> 6ffe92b — fix kernel panic regression from #67' (#69) from claude-noether/marfrit-packages:noether/daedalus-dkms-bump-6ffe92b into main ... Reviewed-on: #69	2026-05-21 12:00:15 +00:00
claude-noether	a0be2dcc9f	daedalus-v4l2-dkms: 79256dc -> 6ffe92b — fix kernel panic from #7 ... Kernel-only bump. Fixes the hard-reboot regression introduced by the daedalus-v4l2#7 split-completion design and observed on higgs (Pi CM5) during the first mpv vaapi-copy playback of 720p H.264: device_run now removes src + dst from m2m_ctx's rdy_queue at the moment it picks them up, not at buf_done time. Without this, a parked dst_buf (waiting for libavcodec's display-order release) stayed in the rdy_queue and got re-picked by the next device_run after SRC_CONSUMED's job_finish released the scheduler — two inflight entries on the same vb2_buffer, later HAS_PIXELS calls list_del on an already-detached list_head, panic. DAEDALUS_PROTO_VERSION stays at 1 — daemon (userspace daedalus-v4l2) need NOT bump in lockstep with this DKMS update. The existing daedalus-v4l2 0.1.0+r28+g79256dc is wire-compatible with daedalus-v4l2-dkms 0.1.0+r30+g6ffe92b. Refs: * reauktion/daedalus-v4l2#8	2026-05-21 13:56:42 +02:00