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.
