marfrit/marfrit-packages
0
0
Fork 1
Code Issues 2 Pull Requests Actions Packages Projects Releases Wiki Activity

libva-v4l2-request-fourier: -Db_lto=false (closes #17) #18

Merged
marfrit merged 1 commits from claude-noether/marfrit-packages:noether/libva-disable-lto into main 2026-05-16 16:39:57 +00:00
Conversation 0 Commits 1 Files Changed 1
+10 -2
claude-noether commented 2026-05-15 19:04:16 +00:00
Contributor
Copy Link
Copy Source

Closes #17. The CI binary at 1.0.0.r348.7ac934e-1 segfaults on HEVC vaEndPicture while the same source built by hand on the consumer host works fine. Root cause: arch-meson's wrapper hard-codes -D b_lto=true regardless of /etc/makepkg.conf's OPTIONS=(..., !lto, ...), so the CI binary still gets cross-function ICF under -O2 + LTO, which folds a per-codec helper across the codec dispatch and feeds HEVC the wrong instance.

Why only HEVC

HEVC is the only campaign codec that submits a 4-struct control chain per frame (SPS + PPS + DECODE_PARAMS + SLICE_PARAMS). The iter25/iter31 fixes hinge on which struct each field lives in. When ICF merges a helper across H.264/MPEG-2/VP8/VP9 (single-control-struct) and HEVC paths, the wrong instance's local-stack layout is invoked → SEGV in a structured-fill that overshoots. The other 4 codecs survive by accident.

Fix

Single-flag change in build():

-    arch-meson build --buildtype=release
+    arch-meson build --buildtype=release -Db_lto=false

pkgrel 1 -> 2. Inline comment in PKGBUILD explains why b_lto=false is required despite makepkg.conf already saying !lto — arch-meson overrides that.

Expected binary shape after fix

Per #17's bisection:

Build Size HEVC
arch-meson + release (no -Db_lto) 145 KB ✓
arch-meson + release + -Db_lto=false (this PR) ~145 KB expected ✓
Current CI (LTO leaks through) 133 KB SEGV
arch-meson + release + -flto (LTO-forced reproducer) 76 KB SEGV

Verification plan after merge

  1. Rebuild 1.0.0.r348.7ac934e-2 on a build host (boltzmann or fermi)
  2. Verify size ≈ 145 KB (LTO-free shape)
  3. Install on fresnel; run the #17 reproducer: 
    LIBVA_DRIVER_NAME=v4l2_request    ffmpeg -hide_banner -loglevel error        -hwaccel vaapi -hwaccel_output_format vaapi        -i bbb_60s_720p.hevc.mp4        -vf "hwdownload,format=nv12" -frames:v 20 -f rawvideo -pix_fmt nv12 /tmp/out.yuv
    Should exit 0 with non-empty /tmp/out.yuv.
  4. Spot-check the other 4 codecs to confirm no regression.
  5. Test firefox-fourier HEVC autoplay on fresnel — HW path should re-engage.

Out of scope for this PR

  • CI smoke-test ($pkg + chroot + ffmpeg run) that catches this class pre-publish — separate workflow improvement; tracked-in-issue.
  • Whether the same arch-meson ICF issue affects other fourier packages (qt6, ffmpeg, mpv, kwin) — they all use cmake --build not arch-meson, so different exposure surface; not expected.

Bot: claude-noether

Closes #17. The CI binary at `1.0.0.r348.7ac934e-1` segfaults on HEVC `vaEndPicture` while the same source built by hand on the consumer host works fine. Root cause: `arch-meson`'s wrapper hard-codes `-D b_lto=true` regardless of `/etc/makepkg.conf`'s `OPTIONS=(..., !lto, ...)`, so the CI binary still gets cross-function ICF under `-O2 + LTO`, which folds a per-codec helper across the codec dispatch and feeds HEVC the wrong instance. ## Why only HEVC HEVC is the only campaign codec that submits a 4-struct control chain per frame (SPS + PPS + DECODE_PARAMS + SLICE_PARAMS). The iter25/iter31 fixes hinge on which struct each field lives in. When ICF merges a helper across H.264/MPEG-2/VP8/VP9 (single-control-struct) and HEVC paths, the wrong instance's local-stack layout is invoked → SEGV in a structured-fill that overshoots. The other 4 codecs survive by accident. ## Fix Single-flag change in `build()`: ```diff - arch-meson build --buildtype=release + arch-meson build --buildtype=release -Db_lto=false ``` `pkgrel 1 -> 2`. Inline comment in PKGBUILD explains why `b_lto=false` is required despite makepkg.conf already saying `!lto` — arch-meson overrides that. ## Expected binary shape after fix Per #17's bisection: | Build | Size | HEVC | |---|---|---| | `arch-meson + release` (no `-Db_lto`) | 145 KB | ✓ | | **`arch-meson + release + -Db_lto=false`** (this PR) | **~145 KB** | **expected ✓** | | Current CI (LTO leaks through) | 133 KB | SEGV | | `arch-meson + release + -flto` (LTO-forced reproducer) | 76 KB | SEGV | ## Verification plan after merge 1. Rebuild `1.0.0.r348.7ac934e-2` on a build host (boltzmann or fermi) 2. Verify size ≈ 145 KB (LTO-free shape) 3. Install on fresnel; run the #17 reproducer: ```sh LIBVA_DRIVER_NAME=v4l2_request ffmpeg -hide_banner -loglevel error -hwaccel vaapi -hwaccel_output_format vaapi -i bbb_60s_720p.hevc.mp4 -vf "hwdownload,format=nv12" -frames:v 20 -f rawvideo -pix_fmt nv12 /tmp/out.yuv ``` Should exit 0 with non-empty `/tmp/out.yuv`. 4. Spot-check the other 4 codecs to confirm no regression. 5. Test firefox-fourier HEVC autoplay on fresnel — HW path should re-engage. ## Out of scope for this PR - CI smoke-test ($pkg + chroot + ffmpeg run) that catches this class pre-publish — separate workflow improvement; tracked-in-issue. - Whether the same `arch-meson` ICF issue affects other fourier packages (qt6, ffmpeg, mpv, kwin) — they all use `cmake --build` not `arch-meson`, so different exposure surface; not expected. Bot: claude-noether
claude-noether added 1 commit 2026-05-15 19:04:16 +00:00
libva-v4l2-request-fourier: -Db_lto=false (closes #17) b648276122 
CI binary segfaulted on HEVC vaEndPicture even though
/etc/makepkg.conf has OPTIONS=(... !lto ...). Root cause: arch-meson's
wrapper hard-codes `-D b_lto=true` regardless of makepkg.conf, so
the binary still gets cross-function ICF (Identical Code Folding)
under -O2 + LTO.

HEVC is the only codec in the campaign that submits a per-frame chain
of 4 control structs (SPS + PPS + DECODE_PARAMS + SLICE_PARAMS); ICF
finds a near-duplicate per-codec helper across the codec dispatch and
merges them, then the wrong instance's local stack layout is invoked
on the HEVC path → SEGV. The other 4 codecs (H.264, VP8, VP9, MPEG-2)
submit fewer/simpler control structs and tolerate the folding by
accident.

Empirical confirmation from the issue body's binary bisection:

  meson build (default debugoptimized)     485 KB   HEVC ✓
  arch-meson + --buildtype=release          145 KB   HEVC ✓
  arch-meson + release + -flto              76 KB   HEVC SEGV
  CI build (this package, 7ac934e-1)        133 KB   HEVC SEGV

Fix: append `-Db_lto=false` to the arch-meson invocation.
pkgrel 1 -> 2.
marfrit merged commit 697413103d into main 2026-05-16 16:39:57 +00:00
marfrit referenced this issue from a commit 2026-05-17 20:22:31 +00:00
lmcp: 1.0.0~rc1 -> 1.1.0
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
marfrit (Markus Fritsche)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: marfrit/marfrit-packages#18
Delete Branch "claude-noether/marfrit-packages:noether/libva-disable-lto"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?