marfrit
a4e7d8ab90
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>
130 lines
6.0 KiB
Plaintext
130 lines
6.0 KiB
Plaintext
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.
|