Files
panvk-bifrost/mesa-panvk-bifrost/phase0_findings_iter10.md
T
marfrit a4e7d8ab90 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>
2026-05-23 05:25:37 +02:00

5.4 KiB
Raw Blame History

Phase 0 — substrate for iter10

Opened 2026-05-20 after iter9 close GREEN (3-point check passed; campaign primary goal hit).

iter10 is the polish iter — known cosmetic / hygiene items left over from iter9. Not load-bearing for the user-facing functionality.

Locked research question — iter10

Eliminate the --disable-gpu-sandbox dependency in brave-vulkan (so launches don't emit the Chromium security warning), and pin sha256sums in the PKGBUILD (replace the SKIP placeholder per Arch packaging hygiene). Re-run the 3-point check: PR merged, CI green + new artifact at packages.reauktion.de, fresh consumer install + brave-vulkan launches WITHOUT the sandbox warning.

Why this shape

iter9 closed the campaign primary goal, but two known-not-clean items survived:

  1. --disable-gpu-sandbox warning. The brave-vulkan wrapper currently passes --no-sandbox --disable-gpu-sandbox because the GPU process sandbox filters VK_ICD_FILENAMES (env var stripping during sandbox setup), and without that env the GPU process can't find our custom ICD at /usr/lib/panvk-bifrost/icd.json. Chromium prints a warning at launch about reduced security. Cosmetic but worth fixing — production-quality should not require sandbox bypass.

  2. sha256sums=SKIP in arch/mesa-panvk-bifrost/PKGBUILD. Matches the sibling fourier-fork PKGBUILD convention ('SKIP'), but for our tarball source (mesa-26.0.6.tar.xz from archive.mesa3d.org) we can pin a real hash since the upstream tarball is fixed. Mostly hygiene; tightens supply-chain assurance.

The WebGL gap (transform_feedback) and VAAPI codec are NOT in iter10 scope — both are months of RE work or out-of-campaign concerns.

Hypothesis space — for the sandbox piece

(α) Install ICD JSON at default loader path (/usr/share/vulkan/icd.d/panvk_bifrost.json). The Vulkan loader scans /usr/share/vulkan/icd.d/ automatically. If our ICD is there, no env var override needed. GPU sandbox doesn't need bypass.

  • Risk: stock Mesa already ships /usr/share/vulkan/icd.d/panfrost_icd.json pointing at /usr/lib/libvulkan_panfrost.so. Two ICD JSONs with the same panfrost device → Vulkan loader sees two ICDs for the same physical device. Loader's behavior is implementation-defined (may pick one randomly, may load both as separate physical devices, may error).
  • Mitigation: name the ICD JSON file alphabetically before panfrost_icd.json so it's picked first (panvk_bifrost_*.json). Or use MESA_VK_VERSION_OVERRIDE-style mechanism inside the JSON (not sure that exists). Or: replace stock Mesa's ICD via conflicts=() in PKGBUILD (sweeping change, probably wrong direction).

(β) Chromium --vulkan-icd-filename or equivalent flag. If Chromium has a flag that tells the GPU process which Vulkan ICD JSON to use (without relying on VK_ICD_FILENAMES env var), we can avoid --disable-gpu-sandbox entirely. The flag would be picked up by the GPU process before sandbox setup strips env.

  • Risk: flag may not exist. Need to probe Chromium 147 source / brave --help (Brave has no --help, but chrome://flags may list internal ones).
  • Probe: strings /opt/brave-bin/brave 2>/dev/null | grep -iE 'vulkan.*icd|icd.*filename' on ohm.

(γ) Wrap the sandbox-bypass differently. E.g., --gpu-sandbox-allow-sysv-shm or some narrower sandbox-permissive flag. Unlikely to help with env var filtering specifically.

Phase 1 plan

  1. Probe Chromium 147 for --vulkan-icd-filename or equivalent (β path).
  2. If (β) exists, update brave-vulkan to use it instead of VK_ICD_FILENAMES env var; drop --disable-gpu-sandbox from the wrapper.
  3. If (β) doesn't exist, try (α): rename the ICD JSON to a path the loader picks up automatically (e.g. /usr/share/vulkan/icd.d/00-panvk-bifrost.json00- prefix to win the alphabetical pick). Update PKGBUILD's package(). Test on ohm — confirm vulkaninfo picks our driver, then test brave-vulkan WITHOUT the sandbox bypass flag.
  4. Pin sha256sums for mesa-26.0.6.tar.xz (compute hash locally, paste into PKGBUILD).
  5. Bump pkgrel=2 (or pkgver if patches change).

In-scope (LOCKED 2026-05-20 for iter10)

  • Eliminate --disable-gpu-sandbox from brave-vulkan wrapper, OR move to a narrower flag.
  • Pin sha256sums in PKGBUILD (replace SKIP for the Mesa tarball source).
  • Test on ohm via pacman -S of the rebuilt package.
  • 3-point check completion (PR merged, CI green + new artifact, consumer install validates).

Out-of-scope (LOCKED 2026-05-20 for iter10)

  • --no-sandbox (Brave renderer sandbox) — separate from GPU sandbox; may need to stay for other reasons.
  • WebGL / VK_EXT_transform_feedback — bigger Bifrost RE work; standalone iter or campaign extension.
  • VAAPI vaInitialize failed — libva-multiplanar territory.
  • README charter update — operator-owned, not iter10.
  • Maintained Mesa fork (vs. PKGBUILD-level patches) — iter9 chose sed in prepare(), keep it.

Reference