302 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
marfrit	190f810843	Merge pull request 'ffmpeg-v4l2-request-fourier: flip libavcodec daedalus ctx no_qpu → qpu-capable (0013)' (#104) from claude-noether/marfrit-packages:noether/h264-ctx-qpu-capable into main ... Reviewed-on: #104	2026-05-25 19:25:30 +00:00
claude-noether	9c70ffffe7	ffmpeg-v4l2-request-fourier: flip libavcodec daedalus ctx no_qpu → qpu-capable (0014) ... (Renumbered from 0013 — PR #102 landed 0013-h264-deblock-chroma-intra while this PR was open, so the next free slot is 0014.) Patches 0003 (IDCT 4x4) and 0007 (qpel mc20) created the libavcodec.so process-global daedalus_ctx via daedalus_ctx_create_no_qpu(). Rationale at the time: cycle 6/9 had only CPU NEON paths, so a QPU-capable ctx would have meant pointless Vulkan init in every host process. Two things changed since: 1. Every H.264 hot-path primitive now has a V3D7 compute shader. IDCT 4x4/8x8 + 8 deblock variants (luma+chroma × V+H × inter+intra) + 30 qpel positions. See daedalus-fourier PRs #28-#35. 2. Dispatch overhead has been hammered down — buffer pool in v3d_runner + persistent command buffer. daedalus-fourier PR #36 bench on hertz (Pi 5 V3D 7.1, 30 iters x 5 warmup): 1080p worst-case sum (IDCT4 + deblock luma + qpel mc22): CPU NEON only: 5.57 ms QPU only: 1.30 ms (CPU/QPU sum ratio = 4.30x) PR #10's CPU-4x-faster-than-QPU verdict (which justified the original no_qpu ctx choice) is reversed by ~17x. This commit adds 0014-h264-ctx-qpu-capable.patch which flips both H.264 TUs (h264_idct_daedalus.c, h264_qpel_daedalus.c) from daedalus_ctx_create_no_qpu() to daedalus_ctx_create(). daedalus_ctx_create() probes for a usable Vulkan device and falls back to no_qpu mode if unavailable, so this is safe on hosts without V3D (x86 build runners, Debian aarch64 builders without renderD, etc.). Hosts WITH V3D (Pi 5 deployment targets) now route the H.264 hot-path through V3D compute instead of CPU NEON. Wired into both arch PKGBUILD (source[] + prepare()) and debian build-deb.sh; both pkgrel bumped 10 → 11. Refs reauktion/daedalus-fourier!36.	2026-05-25 21:18:18 +02:00
marfrit	520f2fce33	Merge pull request 'mesa-panvk-bifrost r9: bump maxImageDimension3D to 2048 (iter22, unblocks Dawn/WebGPU)' (#103) from claude-noether/marfrit-packages:mesa-panvk-bifrost-r9 into main ... Reviewed-on: #103	2026-05-25 18:17:16 +00:00
marfrit	e323aa2316	mesa-panvk-bifrost r9: bump maxImageDimension3D to 2048 (iter22, unblocks Dawn/WebGPU) ... 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>	2026-05-25 15:54:18 +02:00
marfrit	875156782e	Merge pull request 'ffmpeg-v4l2-request-fourier: route H.264 chroma intra deblock (4:2:0) through daedalus-fourier (0013)' (#102) from claude-noether/marfrit-packages:noether/h264-substitute-deblock-chroma-intra into main ... Reviewed-on: #102	2026-05-25 12:48:19 +00:00
claude-noether	8f9487d355	ffmpeg-v4l2-request-fourier: route H.264 chroma intra deblock (4:2:0) through daedalus-fourier (0013) ... 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.	2026-05-25 14:22:02 +02:00
marfrit	f07824adb7	Merge pull request 'ffmpeg-v4l2-request-fourier: route remaining H.264 qpel 8x8 positions through daedalus-fourier (0012)' (#101) from claude-noether/marfrit-packages:noether/h264-substitute-qpel-rest into main ... Reviewed-on: #101	2026-05-25 12:19:55 +00:00
claude-noether	2732a022f8	ffmpeg-v4l2-request-fourier: route remaining H.264 qpel 8x8 positions through daedalus-fourier (0012) ... 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.	2026-05-25 14:05:56 +02:00
marfrit	57f73f1afb	Merge pull request 'ffmpeg-v4l2-request-fourier: route H.264 chroma DC Hadamard through daedalus-fourier (0011)' (#100) from claude-noether/marfrit-packages:noether/h264-substitute-chroma-dc into main ... Reviewed-on: #100	2026-05-25 12:03:08 +00:00
claude-noether	d8aa3aae8d	ffmpeg-v4l2-request-fourier: route H.264 chroma DC Hadamard through daedalus-fourier (0011) ... 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.	2026-05-25 13:39:54 +02:00
marfrit	1f58ff2b6b	Merge pull request 'ffmpeg-v4l2-request-fourier: route H.264 luma intra deblock through daedalus-fourier (0010)' (#99) from claude-noether/marfrit-packages:noether/h264-substitute-deblock-intra into main ... Reviewed-on: #99	2026-05-25 11:28:33 +00:00
claude-noether	45be17fbdf	ffmpeg-v4l2-request-fourier: route H.264 luma intra deblock through daedalus-fourier (0010) ... 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.	2026-05-25 13:21:00 +02:00
marfrit	7b9bb9b2d0	Merge pull request 'ffmpeg-v4l2-request-fourier: route H.264 chroma v/h deblock through daedalus-fourier (0009)' (#98) from claude-noether/marfrit-packages:noether/h264-substitute-deblock-chroma into main ... Reviewed-on: #98	2026-05-25 11:18:15 +00:00
claude-noether	babb280410	ffmpeg-v4l2-request-fourier: route H.264 chroma v/h deblock through daedalus-fourier (0009) ... 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.	2026-05-25 13:16:45 +02:00
marfrit	5b48d1c743	Merge pull request 'ffmpeg-v4l2-request-fourier: route H.264 luma-h deblock through daedalus-fourier (0008)' (#97) from claude-noether/marfrit-packages:noether/h264-substitute-deblock-luma-h into main ... Reviewed-on: #97	2026-05-25 11:14:26 +00:00
claude-noether	624f83e877	ffmpeg-v4l2-request-fourier: route H.264 luma-h deblock through daedalus-fourier (0008) ... 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.	2026-05-25 13:10:05 +02:00
marfrit	902de73a02	Merge pull request 'mesa-panvk-bifrost r7: fix XFB store channel-extract for packed varyings (iter19)' (#96) from claude-noether/marfrit-packages:mesa-panvk-bifrost-r7 into main ... Reviewed-on: #96	2026-05-25 09:22:47 +00:00
marfrit	c14c22f942	mesa-panvk-bifrost r7: fix XFB store channel-extract for packed varyings (iter19) ... 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>	2026-05-25 11:16:56 +02:00
marfrit	b113e053f0	Merge pull request 'aish: package v0.1.0 for arch + debian' (#95) from claude-noether/marfrit-packages:noether/aish-v0.1.0-package into main ... Reviewed-on: #95	2026-05-24 22:40:53 +00:00
marfrit	8ec4c57ad7	aish: package v0.1.0 for arch + debian ... 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>	2026-05-25 00:35:01 +02:00
marfrit	beb09c4863	Merge pull request 'mesa-panvk-bifrost: r5 -> r6 — advertise VK_EXT_legacy_dithering on Bifrost' (#94) from claude-noether/marfrit-packages:noether/mesa-panvk-bifrost-r6-legacy-dithering into main ... Reviewed-on: #94	2026-05-24 22:28:58 +00:00
marfrit	7708744eb2	mesa-panvk-bifrost: r5 -> r6 — advertise VK_EXT_legacy_dithering on Bifrost ... 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>	2026-05-25 00:23:40 +02:00
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