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

Track Karlman rkvdec H.264 High10 / 4:2:2 patch series — mmind v7.0 has v6-era, upstream v10 (Sept 2024) + mainline merge candidate #19

New Issue
Closed
opened 2026-05-17 16:48:47 +00:00 by claude-noether · 1 comment
claude-noether commented 2026-05-17 16:48:47 +00:00
Collaborator
Copy Link
Copy Source

Summary

Filed as a side-by-side companion to marfrit/marfrit-packages#21 (ffmpeg-v4l2-request userspace plumbing) and marfrit/libva-v4l2-request-fourier#4 (iter39 Option B). The kernel side is already functional for Hi10P/Main10 in linux-fresnel-fourier 7.0-14 (mmind v7.0 baseline) — but the patch series authored by Jonas Karlman / Kwiboo has evolved beyond what mmind v7.0 carries, and the mainline merge state should be tracked so we know when to rebuild kernels with a newer baseline.

Current state

Verified on boltzmann (~/src/kernel-agent-bootstrap/baseline/linux-mmind-v7.0/) 2026-05-17:

  • drivers/media/platform/rockchip/rkvdec/rkvdec.c::rkvdec_h264_ctrl_descs sets cfg.max = V4L2_MPEG_VIDEO_H264_PROFILE_HIGH_422_INTRA with menu_skip_mask excluding only EXTENDED + HIGH_444_PREDICTIVE.
  • rkvdec_h264_decoded_fmts[] includes V4L2_PIX_FMT_NV15 (10-bit 4:2:0) and V4L2_PIX_FMT_NV20 (10-bit 4:2:2) entries.
  • rkvdec-h264-common.c::196 has the bit_depth_luma_minus8 == 2 decode path.
  • S_FMT(CAPTURE, NV15) succeeds on RK3399 with sizeimage=2188800, bytesperline=1600 for 1280×720.

That's the v6-era of Karlman's series (per kernel 6.6 changelog references from minimyth2). v6 was 2024-09; the series went to v10 by Sept 2024 on linux-media (https://patchwork.kernel.org/project/linux-media/cover/20240909192522.1076704-1-jonas@kwiboo.se/).

What to track

  1. Does Karlman v10 differ materially from what mmind v7.0 carries? Diff ~/src/kernel-agent-bootstrap/baseline/linux-mmind-v7.0/drivers/media/platform/rockchip/rkvdec/ against https://github.com/Kwiboo/linux-rockchip branch linuxtv-rkvdec-high-10-v6 (or the latest tip). Likely refinements to error paths / control validation; not a functional gap but worth confirming.

  2. Has the series landed in mainline? Last known status at 2026-05 was v10 in review on linux-media. If a rkvdec_h264 10-bit-related commit lands in mainline 7.x or 8.x, a kernel-agent baseline bump to that mainline tag pulls it in cleanly.

  3. Companion patches needed for full functionality: Kwiboo's gist (https://gist.github.com/Kwiboo/f4ac15576b2c72887ae2bc5d58b5c865) prescribes BOTH the kernel branch (linuxtv-rkvdec-high-10-v6) AND the ffmpeg branch (v4l2request-2024-v2-rkvdec) — confirming kernel patches alone aren't sufficient without userspace. We're tracking userspace in marfrit/marfrit-packages#21; this issue is the kernel side of the same gap.

Action when triggered

If a newer mmind tag or mainline commit incorporates Karlman v10 (or later) plus other fixes that benefit fresnel/ampere:

  • Update marfrit-packages/arch/linux-fresnel-fourier/PKGBUILD _baseversion to the new tag.
  • Run kernel-agent build → produce linux-fresnel-fourier 7.1-1 (or whichever pkgrel).
  • Per feedback_backup_before_module_replace: MANDATORY backup + USB-stick recovery image before installing the new kernel on fresnel.
  • Re-run phase7_iter39_test_rig.sh to confirm Hi10P decode produces non-zero output (only if marfrit-packages#21 has also closed).

References

Closing

Close when:

  • A newer mmind baseline (or mainline tag) with the latest Karlman series is incorporated into marfrit-packages/arch/linux-fresnel-fourier AND deployed to fresnel + ampere.
  • OR: the userspace ffmpeg plumbing (marfrit-packages#21) becomes available and we verify the v6-era kernel patches are sufficient — in which case this issue closes as "v6 was enough."
## Summary Filed as a side-by-side companion to `marfrit/marfrit-packages#21` (ffmpeg-v4l2-request userspace plumbing) and `marfrit/libva-v4l2-request-fourier#4` (iter39 Option B). The kernel side is already functional for Hi10P/Main10 in `linux-fresnel-fourier 7.0-14` (mmind v7.0 baseline) — but the patch series authored by Jonas Karlman / Kwiboo has evolved beyond what mmind v7.0 carries, and the mainline merge state should be tracked so we know when to rebuild kernels with a newer baseline. ## Current state Verified on boltzmann (`~/src/kernel-agent-bootstrap/baseline/linux-mmind-v7.0/`) 2026-05-17: - `drivers/media/platform/rockchip/rkvdec/rkvdec.c::rkvdec_h264_ctrl_descs` sets `cfg.max = V4L2_MPEG_VIDEO_H264_PROFILE_HIGH_422_INTRA` with `menu_skip_mask` excluding only EXTENDED + HIGH_444_PREDICTIVE. - `rkvdec_h264_decoded_fmts[]` includes `V4L2_PIX_FMT_NV15` (10-bit 4:2:0) and `V4L2_PIX_FMT_NV20` (10-bit 4:2:2) entries. - `rkvdec-h264-common.c::196` has the `bit_depth_luma_minus8 == 2` decode path. - `S_FMT(CAPTURE, NV15)` succeeds on RK3399 with `sizeimage=2188800, bytesperline=1600` for 1280×720. That's the **v6-era** of Karlman's series (per kernel 6.6 changelog references from minimyth2). v6 was 2024-09; the series went to **v10** by Sept 2024 on linux-media (https://patchwork.kernel.org/project/linux-media/cover/20240909192522.1076704-1-jonas@kwiboo.se/). ## What to track 1. **Does Karlman v10 differ materially from what mmind v7.0 carries?** Diff `~/src/kernel-agent-bootstrap/baseline/linux-mmind-v7.0/drivers/media/platform/rockchip/rkvdec/` against `https://github.com/Kwiboo/linux-rockchip` branch `linuxtv-rkvdec-high-10-v6` (or the latest tip). Likely refinements to error paths / control validation; not a functional gap but worth confirming. 2. **Has the series landed in mainline?** Last known status at 2026-05 was v10 in review on linux-media. If a `rkvdec_h264` 10-bit-related commit lands in mainline 7.x or 8.x, a kernel-agent baseline bump to that mainline tag pulls it in cleanly. 3. **Companion patches needed for full functionality**: Kwiboo's gist (https://gist.github.com/Kwiboo/f4ac15576b2c72887ae2bc5d58b5c865) prescribes BOTH the kernel branch (`linuxtv-rkvdec-high-10-v6`) AND the ffmpeg branch (`v4l2request-2024-v2-rkvdec`) — confirming kernel patches alone aren't sufficient without userspace. We're tracking userspace in `marfrit/marfrit-packages#21`; this issue is the kernel side of the same gap. ## Action when triggered If a newer mmind tag or mainline commit incorporates Karlman v10 (or later) plus other fixes that benefit fresnel/ampere: - Update `marfrit-packages/arch/linux-fresnel-fourier/PKGBUILD` `_baseversion` to the new tag. - Run kernel-agent build → produce `linux-fresnel-fourier 7.1-1` (or whichever pkgrel). - Per `feedback_backup_before_module_replace`: MANDATORY backup + USB-stick recovery image before installing the new kernel on fresnel. - Re-run `phase7_iter39_test_rig.sh` to confirm Hi10P decode produces non-zero output (only if `marfrit-packages#21` has also closed). ## References - Kwiboo recipe gist: https://gist.github.com/Kwiboo/f4ac15576b2c72887ae2bc5d58b5c865 - Karlman v6 LWN summary: https://lwn.net/Articles/950434/ - Karlman v10 patchwork cover: https://patchwork.kernel.org/project/linux-media/cover/20240909192522.1076704-1-jonas@kwiboo.se/ - Cross-issue (userspace): `marfrit/marfrit-packages#21` - Cross-issue (libva backend): `marfrit/libva-v4l2-request-fourier#4` - Empirical evidence: `marfrit/fresnel-fourier:phase7_iter39_close.md` @ `a4855f7` - Memory: `feedback_rk3399_h264_hi10p_advertised_not_functional.md` ## Closing Close when: - A newer mmind baseline (or mainline tag) with the latest Karlman series is incorporated into `marfrit-packages/arch/linux-fresnel-fourier` AND deployed to fresnel + ampere. - OR: the userspace ffmpeg plumbing (`marfrit-packages#21`) becomes available and we verify the v6-era kernel patches are sufficient — in which case this issue closes as "v6 was enough."
claude-noether commented 2026-05-18 09:46:16 +00:00
Author
Collaborator
Copy Link
Copy Source

Closing 2026-05-18 — issue's own second close criterion is met: "v6 was enough."

Close when: [...] OR: the userspace ffmpeg plumbing (marfrit-packages#21) becomes available and we verify the v6-era kernel patches are sufficient — in which case this issue closes as "v6 was enough."

Verification today (during marfrit-packages#21 triage + fix)

  1. Userspace ffmpeg plumbing landed: marfrit/marfrit-packages#21 + PR #26 merged at commit 7542989f. NV15→P010 unpack patch in ffmpeg-v4l2-request-fourier pkgrel=5.

  2. v6-era kernel patches in linux-fresnel-fourier 7.0-14 (mmind v7.0) are sufficient for H.264 Hi10P decode end-to-end:

    • Kernel side: S_FMT(CAPTURE, NV15) succeeds, decode runs to completion
    • Userspace + kernel together: 20-frame mid-fixture decode is bit-exact HW==SW on RK3399, sha 7d9b66d48d8f17b2281da1881c663ecc31722bb218aba1ae23bf28d07aa66b08
    • Overturns the prior feedback_rk3399_h264_hi10p_advertised_not_functional.md memory entry (the "all-zero" was the 5-frame fadein title card, not a silicon limitation)

The Hi10P leg of this tracker is therefore done. Karlman v10 → mainline tracking is still useful if we ever rebase mmind, but it doesn't gate any current work — no functional gap remains for the workloads on the fleet.

What's NOT covered by this closure

H.264 4:2:2 (Hi422P / NV20) is in the issue title but practically separate from Hi10P. NV20 unpack in ffmpeg-v4l2-request-fourier PR #26 is still ENOSYS (only NV15→P010 implemented) — so even with the v10 kernel patches landed, 4:2:2 would need a follow-up userspace patch. Given Hi422P is rare in the wild (basically only intra-only / proxy / mastering content), it's a "open issue when a concrete need arises" rather than a tracking thread.

Also, the HEVC half of the Karlman ecosystem has been independently scoped out per feedback_hevc_out_of_scope_ampere — HEVC on ampere is EWONTFIX; HEVC on fresnel works at the iter38/iter39 baseline already.

Action items now retired

  • Diff mmind v7.0 vs Karlman v10 — not blocking anything; if mmind rebases later, the diff happens then.
  • Track mainline merge state — not blocking anything; if a useful tag lands, kernel-agent baseline bump pulls it in.
  • Re-run phase7_iter39_test_rig.sh — partially done today (Hi10P leg bit-exact); Main10 leg still gated on a real Main10 fixture, tracked in libva-v4l2-request-fourier#4.

Closing.

**Closing 2026-05-18 — issue's own second close criterion is met: "v6 was enough."** > Close when: [...] OR: the userspace ffmpeg plumbing (`marfrit-packages#21`) becomes available and we verify the v6-era kernel patches are sufficient — in which case this issue closes as "v6 was enough." ## Verification today (during marfrit-packages#21 triage + fix) 1. **Userspace ffmpeg plumbing landed**: [marfrit/marfrit-packages#21](https://git.reauktion.de/marfrit/marfrit-packages/issues/21) + PR #26 merged at commit `7542989f`. NV15→P010 unpack patch in `ffmpeg-v4l2-request-fourier pkgrel=5`. 2. **v6-era kernel patches in `linux-fresnel-fourier 7.0-14` (mmind v7.0) are sufficient** for H.264 Hi10P decode end-to-end: - Kernel side: `S_FMT(CAPTURE, NV15)` succeeds, decode runs to completion - Userspace + kernel together: 20-frame mid-fixture decode is **bit-exact HW==SW** on RK3399, sha `7d9b66d48d8f17b2281da1881c663ecc31722bb218aba1ae23bf28d07aa66b08` - Overturns the prior `feedback_rk3399_h264_hi10p_advertised_not_functional.md` memory entry (the "all-zero" was the 5-frame fadein title card, not a silicon limitation) The Hi10P leg of this tracker is therefore done. Karlman v10 → mainline tracking is still useful if we ever rebase mmind, but it doesn't gate any current work — no functional gap remains for the workloads on the fleet. ## What's NOT covered by this closure H.264 4:2:2 (Hi422P / NV20) is in the issue title but practically separate from Hi10P. NV20 unpack in `ffmpeg-v4l2-request-fourier` PR #26 is still ENOSYS (only NV15→P010 implemented) — so even with the v10 kernel patches landed, 4:2:2 would need a follow-up userspace patch. Given Hi422P is rare in the wild (basically only intra-only / proxy / mastering content), it's a "open issue when a concrete need arises" rather than a tracking thread. Also, the HEVC half of the Karlman ecosystem has been independently scoped out per [`feedback_hevc_out_of_scope_ampere`](https://git.reauktion.de/marfrit/kernel-agent/issues/14) — HEVC on ampere is EWONTFIX; HEVC on fresnel works at the iter38/iter39 baseline already. ## Action items now retired - ~~Diff mmind v7.0 vs Karlman v10~~ — not blocking anything; if mmind rebases later, the diff happens then. - ~~Track mainline merge state~~ — not blocking anything; if a useful tag lands, kernel-agent baseline bump pulls it in. - ~~Re-run `phase7_iter39_test_rig.sh`~~ — partially done today (Hi10P leg bit-exact); Main10 leg still gated on a real Main10 fixture, tracked in [libva-v4l2-request-fourier#4](https://git.reauktion.de/marfrit/libva-v4l2-request-fourier/issues/4). Closing.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
EWONTFIX
Triaged 2026-05-18: scoped out indefinitely; reopen-able if real need emerges. (HEVC-on-ampere first batch.)
 area:boltzmann
Touches boltzmann host
 area:fresnel
Touches fresnel host
 area:patch-tree
Touches the scope-tagged patches/ tree
 decision
Pending decision required (no clear default)
 migration
Bootstrap-time migration from existing trees into kernel-agent layout
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claude-ampere (Claude (ampere)) claude-boltzmann (Claude (boltzmann)) claude-noether (Claude (noether)) marfrit (Markus Fritsche)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: marfrit/kernel-agent#19
Delete Branch "%!s()"

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?