forked from marfrit/panvk-bifrost
initial seed: retrofit campaign lineage from local working trees
panvk-bifrost campaigns (r1..r4 Vulkan compositor + r5.video1 Vulkan
video decode) shipped before this repo existed; the deliverable
patches live in marfrit-packages, but the reasoning chain, phase docs,
and source-state evidence lived only in local working trees on the
development host.
This retrofit imports:
- mesa-panvk-bifrost/ — r1..r4 era phase docs (iter1..iter18)
(libmali stub blobs at iter18/blob/ excluded
— 109MB of RE artifacts replaced with a README
pointer)
- mesa-panvk-bifrost-video/ — sibling campaign phase docs + probe
- evidence/ — frozen .tgz source snapshots at each milestone
(basis for the 0005 patch diff generation)
Future iterations should branch off here from day one, so each iter is
a commit rather than a snapshot. See [[feedback-session-local-process-pins]]
for the process drift this retrofit closes.
Total: 1.9 MB across 124 files.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,129 @@
|
||||
iter11 chrome://gpu Graphics Feature Status — captured 2026-05-20 on ohm
|
||||
Brave Browser 148.1.90.122 (auto-updated from 147 during the session)
|
||||
Launch invocation:
|
||||
VK_ICD_FILENAMES=/usr/lib/panvk-bifrost/icd.json
|
||||
PAN_I_WANT_A_BROKEN_VULKAN_DRIVER=1
|
||||
MESA_VK_VERSION_OVERRIDE=1.2
|
||||
LIBVA_DRIVER_NAME=v4l2_request
|
||||
LIBVA_V4L2_REQUEST_VIDEO_PATH=/dev/video1
|
||||
LIBVA_V4L2_REQUEST_MEDIA_PATH=/dev/media0
|
||||
brave --use-gl=disabled
|
||||
--enable-features=Vulkan,VaapiVideoDecoder,VaapiIgnoreDriverChecks
|
||||
--use-vulkan=native
|
||||
--ozone-platform=x11
|
||||
--no-sandbox --disable-gpu-sandbox
|
||||
--ignore-gpu-blocklist
|
||||
chrome://gpu
|
||||
|
||||
Operator-reported Graphics Feature Status table:
|
||||
|
||||
Canvas: Hardware accelerated
|
||||
Direct Rendering Display Compositor: Disabled
|
||||
Compositing: Software only. Hardware acceleration disabled
|
||||
Multiple Raster Threads: Enabled
|
||||
OpenGL: Enabled
|
||||
Rasterization: Hardware accelerated
|
||||
Raw Draw: Disabled
|
||||
Skia Graphite: Disabled
|
||||
TreesInViz: Disabled
|
||||
Video Decode: Hardware accelerated
|
||||
Video Encode: Software only. Hardware acceleration disabled
|
||||
Vulkan: Enabled
|
||||
WebGL: Hardware accelerated but at reduced performance
|
||||
WebGPU: Hardware accelerated but at reduced performance
|
||||
WebGPU interop: Disabled
|
||||
WebNN: Disabled
|
||||
|
||||
===== INTERPRETATION =====
|
||||
|
||||
PRIMARY WIN (iter11 goal):
|
||||
Video Decode: Hardware accelerated.
|
||||
VAAPI engaged via libva-v4l2-request-fourier's v4l2_request driver
|
||||
against rkvdec hardware. Stock Brave's "vaInitialize failed: unknown
|
||||
libva error" line is gone. Combined with iter9's Vulkan compositor,
|
||||
this means H.264 / MPEG-2 / VP8 in-page video will now hardware-decode
|
||||
on PineTab2 instead of grinding the Cortex-A55s.
|
||||
|
||||
CONTEXTUAL WIN (carryover from iter9):
|
||||
Vulkan: Enabled.
|
||||
|
||||
UNEXPECTED RESULT — needs investigation:
|
||||
Compositing: Software only.
|
||||
This is surprising. The iter9 demonstrated the Vulkan compositor is
|
||||
doing real work (operator visually confirmed window rendered, 250 FPS
|
||||
glxgears-via-Zink-on-PanVk separately). Chromium's chrome://gpu
|
||||
reporter says "Software only" but the visible behavior says otherwise.
|
||||
Hypothesis: Chromium's Compositing-status reporter ties to OpenGL
|
||||
context availability; with --use-gl=disabled, the GL context is
|
||||
intentionally absent → reporter says "software" even though Skia GrVk
|
||||
is actually doing GPU work via the Vulkan path. The reporter and the
|
||||
reality may diverge under --use-gl=disabled. Open question for iter12.
|
||||
|
||||
UNEXPECTED RESULT — surprise:
|
||||
WebGL: Hardware accelerated but at reduced performance.
|
||||
WebGPU: Hardware accelerated but at reduced performance.
|
||||
Earlier hypothesis was that WebGL would be broken because ANGLE needs
|
||||
GLES3 which needs VK_EXT_transform_feedback (PanVk-Bifrost doesn't
|
||||
expose). But chrome://gpu says hardware accelerated at reduced perf.
|
||||
Possibilities:
|
||||
- Brave 148's ANGLE has a softer transform_feedback path
|
||||
- Chromium reports "hardware accelerated" optimistically when ANY
|
||||
GPU path is available, even if shaders requiring GLES3 features
|
||||
would fall back internally
|
||||
- The "reduced performance" qualifier is doing heavy lifting
|
||||
Open question for iter12 — actually test a WebGL/WebGPU page.
|
||||
|
||||
OUT OF SCOPE:
|
||||
Video Encode: Software only — rkvenc not exposed via VAAPI on this
|
||||
hardware/stack. Webcam capture would software-encode. Unaffected by
|
||||
iter11.
|
||||
Skia Graphite: Disabled — falling back to classic Skia. Acceptable;
|
||||
Skia/Vulkan still engages via GrVk.
|
||||
|
||||
===== CAMPAIGN CUMULATIVE STATE =====
|
||||
|
||||
PanVk-Bifrost stack on PineTab2 now drives:
|
||||
- Browser chrome rendering via Vulkan compositor (iter9)
|
||||
- Hardware video decode for H.264/MPEG-2/VP8 via VAAPI->rkvdec (iter11)
|
||||
- WebGL/WebGPU "at reduced performance" (this run's surprise; needs verification)
|
||||
- Compositing reporter says "Software only" but visual evidence
|
||||
contradicts (this run's other surprise)
|
||||
|
||||
===== 2026-05-20 update: empirical playback test (operator-driven) =====
|
||||
|
||||
Operator played bbb_1080p30_h264.mp4 in the iter11-flag Brave window.
|
||||
While playback was active:
|
||||
|
||||
Brave processes (top sampled across 3 seconds):
|
||||
PID 6107 renderer: ~70-81% CPU (single core, sustained)
|
||||
PID 5811 gpu-process: ~57-67% CPU
|
||||
PID 5776 main brave: ~3%
|
||||
Other utility/network: ~3-6%
|
||||
|
||||
File descriptors held by each brave PID:
|
||||
PID 5776: /dev/dri/renderD128 (Mali GPU node, Vulkan)
|
||||
PID 5811: /dev/dri/renderD128
|
||||
PID 6107: (no video/dri fds at all)
|
||||
PID 5813 (network): none
|
||||
|
||||
fuser /dev/video1: EMPTY (no process holds the rkvdec node)
|
||||
lsof /dev/media0: EMPTY (no process holds the media controller)
|
||||
|
||||
INTERPRETATION:
|
||||
- The rkvdec hardware decoder is IDLE during playback.
|
||||
- The renderer process is software-decoding H.264 1080p30 via libavcodec
|
||||
on a Cortex-A55 (75% of one core matches the known cost of NEON-
|
||||
accelerated H.264 SW decode at that resolution/framerate).
|
||||
- chrome://gpu's "Video Decode: Hardware accelerated" was optimistic —
|
||||
it reflects "VAAPI initialized successfully" + "compatible profiles
|
||||
found" but NOT "decoded frames actually deliver to compositor".
|
||||
- The likely culprit: --use-gl=disabled blocks Chromium's VAAPI
|
||||
delivery path. The classic chain is VAAPI -> DMA-BUF -> GL texture
|
||||
import -> compositor. With GL disabled, step 3 (GL texture import)
|
||||
has no GL context to bind into. Chromium silently falls back to
|
||||
SW decode while keeping the "available" status on chrome://gpu.
|
||||
|
||||
ITER11 STATUS: vaInitialize succeeds now (iter9 RED gone), VAAPI is
|
||||
recognized as available, but no actual hardware decode happens for the
|
||||
tested playback. Partial GREEN at best. Real HW decode requires
|
||||
unblocking the delivery path — iter12 territory.
|
||||
Reference in New Issue
Block a user