This page replaces the original Phase 3 narrative after a methodological correction by Markus on 2026-04-30 (“did you actually trace, or take cheap stdout statistics?”). The original Phase 3 sat on mpv –term-status-msg counters and /usr/bin/time -v totals. The revised Phase 3 — captured 2026-05-01 — is grounded in perf record –call-graph=dwarf, perf stat -e cache-misses,LLC-load-misses, and strace -e trace=ioctl,mmap,munmap,sendmsg,recvmsg across six contender playback paths.
Validity criterion (Markus 2026-05-01): a measurement is valid only if it identifies, at each handoff boundary, whether a dmabuf fd was passed or a new anonymous mapping appeared. Stdout playback logs are not measurements. Five of six scenarios pass the criterion; the sixth (Brave) has perf record + DSO/symbol attribution but no v2 strace — see §6.
Source clip across all scenarios: bbb_1080p30_h264.mp4 (1920×1080 H.264 Main, 24 fps, sha-16 dcf8a7170fbd49bb). Hardware: ohm (PineTab2, RK3566, Mali-G52 MP2, hantro VPU, kernel 6.19.10-danctnix1-1-pinetab2, mesa 26.0.5, mpv 0.41.0, libplacebo 7.360.1, ffmpeg n8.1 runtime, KWin 6.6.4, Plasma 6.6.4). Compositor: KWin Wayland, ozone-platform=wayland for Brave.
v4l2codecs plugin, present via linux-dmabuf-v1 Wayland protocol.–hwdec=v4l2request –vo=gpu-next — libavcodec + libplacebo. Falls to SW decode because mpv's drmprime-overlay loader fails on Wayland (see §6 finding 5 of original phase3/findings.md).-hwaccel v4l2request refuses to play because ffplay's required Vulkan renderer fails to initialise on Mali-G52 (panvk default-off gate).–intf=qt — bundled libavcodec 58.x (ffmpeg 4.4 packaged at /usr/lib/ffmpeg4.4/) + Qt vout. The bundled libavcodec predates the v4l2request hwaccel landing.v4l2slh264dec0 → glimagesink. HW decode + GL composite.vaInitialize failed: unknown libva error); falls to Chromium's static-linked SW decode in renderer process; renderer→GPU IPC; GPU process composes via Mesa.
DSO-level CPU attribution from perf record –call-graph=dwarf over 15 s steady-state per scenario.
| Scenario | Load stream | Decode (libavcodec or static) | Display handoff (memcpy + GL/Mesa) | Other |
|---|---|---|---|---|
| S1 gst-launch waylandsink | <0.1% libavformat | — (HW decode in V4L2 + libgstv4l2codecs 2.33%) | libwayland-client 3.92%, libc 12.73% (gst plumbing memcpy, not frame data) | kernel 32.24% (V4L2 ioctl + dmabuf protocol traffic) |
| S2 mpv gpu-next | 0.14% libavformat | 70.98% libavcodec | 15.98% libc (of which 14.28% is memcpy, 11.71% under pl_upload_plane → pl_tex_upload), 1.33% libgallium, 0.54% libplacebo | kernel 6.74%, mpv 1.84% |
| S3 ffplay default SW | <0.01% libavformat | 87.21% libavcodec | 5.38% libc (4.08% memcpy on SDL3 vout path), 1.13% libgallium, 0.51% libSDL3 | kernel 3.91% |
| S4 VLC qt | <0.01% libavformat | 75.52% libavcodec.so.58.134 (bundled ffmpeg 4.4) | 17.72% libc (17.35% memcpy on Qt vout), 0.55% libgallium, 0.27% Qt5* | kernel 3.07%, libfaad 2.12% (audio) |
| S5 gst-play playbin | <0.1% libavformat | — (HW decode) | 9.68% libgallium, 1.79% libgstgl, 8.07% libc (1.23% memcpy from gst plumbing) | kernel 27.72%, libfaad 21.45% (audio) |
| S6 Brave renderer | (static) | (static — 91.98% in brave binary) | 2.35% libc (0.86% memcpy in renderer) | kernel 5.60% |
| S6 Brave GPU | — | — | 17.26% libc (12.92% memcpy on renderer→GPU IPC + GL upload), 9.25% libgallium, 3.45% libGLESv2, 0.45% [panfrost] | 44.21% brave (Chromium GPU code), kernel 23.41% |
Headline: load-stream is ≤0.1% on every scenario; decode is the cost sink for SW paths (70-87% libavcodec); display handoff is 12-17% memcpy on every libavcodec-using path AND on Brave's GPU process. The two HW-decode paths (S1, S5) split: S1 has near-zero memcpy, S5 has minimal memcpy (1.23%) but significant libgallium/GL work.
strace -f -e trace=ioctl,mmap,munmap,sendmsg,recvmsg over the ~25 s playback lifetime, post-processed for boundary signals.
| Scenario | V4L2 EXPBUF (dmabuf out) | V4L2 DQBUF (frame deq) | Anon mmap ≥2 MB | Anon mmap total | Decode→buffer path |
|---|---|---|---|---|---|
| S1 gst-launch waylandsink | 13 | 1200 | 10 | 459 MB | dmabuf fd (V4L2 hantro) |
| S2 mpv gpu-next | 0 | 0 | 67 | 2 320 MB | new anon mappings (CPU buffers) |
| S3 ffplay default SW | 0 | 0 | 47 | 1 313 MB | new anon mappings (CPU buffers) |
| S4 VLC qt | 0 | 0 | 53 | 2 483 MB | new anon mappings (CPU buffers) |
| S5 gst-play playbin | 13 | 958 | 34 | 1 723 MB | dmabuf fd (V4L2 hantro) |
| S6 Brave (renderer + gpu) | 0 (no V4L2 path) | 0 | not captured (v2 strace not run) | — | inferred: shmem-IPC from renderer to GPU (no V4L2 dmabuf at the decode boundary; libva failed earlier) |
The 13 EXPBUFs in S1/S5 correspond to 9 V4L2 capture buffers (NV12 1920×1088 single-plane, sizeimage = 3 655 712) plus 4 bitstream-input buffers — matches the Phase 2 §3 substrate finding.
| Scenario | sendmsg | SCM_RIGHTS (fd-pass) | DRM_IOCTL_* | PRIME_FD_TO_HANDLE | buf→compositor path |
|---|---|---|---|---|---|
| S1 gst-launch waylandsink | 1204 | 11 | 0 | 0 | fd passed via linux-dmabuf-v1 protocol — no Mesa, no DRM ioctls |
| S2 mpv gpu-next | 227 | 16 | 19 311 | 0 | libplacebo+Mesa GL composite (CPU upload first) |
| S3 ffplay default SW | 966 | 7 | 10 030 | 0 | SDL3 GL (CPU upload first) |
| S4 VLC qt | 1043 | 24 | 17 388 | 0 | Qt GL vout (CPU upload first) |
| S5 gst-play playbin | 486 | 7 | 23 019 | 22 | dmabuf import via PRIME_FD_TO_HANDLE → GL composite via Mesa |
| S6 Brave (gpu) | not captured | not captured | not captured (v2 strace not run) | not captured | inferred: renderer→GPU shmem + GPU-side GL upload + present (12.92% memcpy on this path per perf) |
Rates per second of playback (≈22 s window):
perf stat -e cache-misses,LLC-load-misses,cycles,instructions -p $PID sleep 10 (no strace overhead).
| Scenario | cache-misses | LLC-load-misses | cycles | instructions | IPC |
|---|---|---|---|---|---|
| S1 gst-launch waylandsink | 2.1 M | 3.0 M | 0.45 G | 0.13 G | 0.29 |
| S2 mpv gpu-next | 94.6 M | 65.1 M | 22.5 G | 9.2 G | 0.41 |
| S3 ffplay default SW | 93.5 M | 59.9 M | 19.5 G | 9.6 G | 0.49 |
| S4 VLC qt | 28.6 M | 15.4 M | 62.6 G | 5.6 G | 0.09 |
| S5 gst-play playbin | 14.3 M | 16.5 M | 4.3 G | 1.3 G | 0.30 |
| S6 Brave renderer | not captured | not captured | not captured | not captured | — |
| S6 Brave gpu | not captured | not captured | not captured | not captured | — |
LLC-load-misses ratios vs. S1 reference:
VLC's 4-core saturation also shows in cycles (62.6 G in 10 s ≈ 6.26 GHz aggregate, near 100% across all 4 cores at 1.4 GHz per core) and IPC of 0.09 (severely cache-bound). Memcpy of 1080p NV12 frames at 24 fps = ~72 MB/sec memory traffic, exactly the workload generating LLC-class miss pressure.
perf report –dsos=[kernel.kallsyms] on the existing perf data (kernel symbols resolve via /proc/kallsyms).
rk_iommu_irq / rockchip_iommu_* (no iommu fault traffic), no panfrost_* software-fallback path symbols, no excessive page-table churn beyond what dmabuf allocation-and-free implies.__arch_copy_to_user for ioctl returns + _raw_spin_unlock_irqrestore for HW decoder completion interrupts + dma-buf allocation/destruction. All “doing the work” symbols.kmem_cache_alloc_noprof 0.22% + vma_interval_tree_insert 0.26% + objects_lookup 0.29%. Together suggests per-frame DRM object allocation rather than buffer reuse on Chromium's GPU side. That's a Chromium-side decision and adds visible kernel cost.The validity-passing data exposes a structural distinction the Phase 3 (original) narrative missed:
The decoder either produces a dmabuf fd (visible as VIDIOC_EXPBUF followed by the fd flowing into the consumer) or it produces frames into CPU-side anonymous memory (visible as mmap(MAP_ANONYMOUS, ≥3 MB, …)). S1 and S5 do the former (13 EXPBUFs each). S2, S3, S4 do the latter (1.3-2.5 GB total anon allocation, of which the steady-state per-frame share is amortised across libavcodec's reused frame-buffer pool).
Once the presentation buffer exists, the consumer either passes a dmabuf fd to the compositor via the Wayland linux-dmabuf-v1 protocol (visible as sendmsg + SCM_RIGHTS on the Wayland socket, 0 DRM_IOCTL_*) or it walks the buffer through Mesa GL+DRM to build a GL texture and present that (visible as thousands of DRM_IOCTL_*/sec).
S1 is the only scenario reaching Level 2. Every other libavcodec or libva-using path stops at Level 1 (best case, S5) or fails Level 1 entirely (S2, S3, S4, S6).
Same decode (HW), same source clip, same compositor — but S1 vs. S5 differ by:
Going through Mesa's GL+DRM path for compositing alone costs ~30% of CPU on this hardware class compared with going through Wayland's linux-dmabuf-v1 protocol directly. That gap exists even when Level 1 is solved. The “buffer-to-display without CPU copy” predicament Markus has been naming is specifically about Level 2.
Re-stating the Phase 4 fix surfaces, ranked against this evidence:
libavcodec drm_prime export to linux-dmabuf-v1 — would lift Level 1 and Level 2 for libavcodec consumers (mpv, ffplay, VLC if linked against current libavcodec). Highest leverage on the libavcodec ecosystem.panvk-1.2-fakeshim Vulkan layer — unblocks Vulkan-side consumers for Level 2 if they use Vulkan-direct dmabuf-import
+ swapchain present instead of GL. Doesn't help GL-anchored consumers (libplacebo's GL backend, SDL3 GL, Qt GL).The empirical rank: B > A > C2 for Markus's stated use cases (Brave, VS Code, web browsing). A lifts the highest-traffic individual workload (browser video decode); B lifts the most consumers across the libavcodec ecosystem with a single change at the right layer. C2 has a narrower lift but is the smallest engineering footprint and would serve as a feasibility vehicle.
Five of six scenarios have validity-passing v2 strace + perf-stat data. Brave (S6) has only the earlier perf record (DSO/symbol attribution, 35 992 renderer + 9 289 GPU samples) plus the Brave subprocess CPU distribution captured 2026-05-01.
What we do know about Brave:
brave (Chromium statically links libavcodec — invisible at DSO level but inside that 92%), 0.86% memcpy in renderer.kmem_cache_alloc_noprof, objects_lookup, vma_interval_tree_insert).vaInitialize failed: unknown libva error), confirming fourier's S4 finding — libva-v4l2-request is the chokepoint for browser HW decode.What we don't know (gap):
The architectural picture for Brave is consistent with what perf shows and with what fourier documented earlier (see fourier README L236-281): no HW decode (libva-v4l2-request multiplanar gap), SW decode in renderer's static ffmpeg, IPC via shared memory to GPU process, GPU process uploads to GL texture and composites. Both Level 1 and Level 2 are CPU-copy.
phase3/cross_player_perf_2026-04-30/ — original perf record DSO/symbol/callgraph for S1-S5 + Brave renderer/gpu (samples-based).phase3/io_cache_2026-05-01/ — v2 strace traces (full lifetime, widened filter) + perf-stat .perfstat files for S1-S5.phase3/findings.md — the original Phase 3 narrative (Findings 1-6) plus the methodology corrections that led here.phase3/research_2026-04-30_panvk_brokenness.md — the panvk/v7 Vulkan-API-version analysis (PAN_I_WANT_A_BROKEN_VULKAN_DRIVER gate, apiVersion = 1.0.335 wall against libplacebo's ≥1.2 minimum).phase3/INDEX.md — full evidence-file map per finding.
Saved to project memory (~/.claude/projects/-home-mfritsche-src-ohm-gl-fix/memory/):
feedback_profile_dont_proxy.md — when locating cycles, run perf/strace, don't infer from program-self counters.feedback_kpi_vs_detail_knowledge.md — before producing an artefact, check whether the facts in reach mandate the content.feedback_measurement_archival.md — every probe writes to a named file in the campaign repo at run time.feedback_outscoping.md — for “find the gap” goals, the deliverable is the gap, never a workaround.feedback_pre_think_problem_space.md — slow-down requests are for territory mapping, not solution selection.feedback_ask_before_user_visible.md — when automation fails on shared user state, asking the user is cheaper than retrying.Phase 3 (revised) ends here. Phase 4 (“the gap” structural documentation, with use-case scoping) is in phase4_2026-04-30; it predates this revised data but its fix-surface ranking is reinforced by §7 above.