fix(slop): headless never reached the GPU — `--gl hw` was software all along
Every bake-off render failed, for two independent reasons, and the second one had
been sitting in this file as a comment asserting the opposite of the truth.
## 1. The playwright browser cache is empty now
`chromeBinary()` scans `~/.cache/ms-playwright` for a full chromium build and
returns `undefined` if it finds none, on the documented theory that this "lets
playwright pick". It does not. Playwright reaches for the exact build it shipped
against — `chromium_headless_shell-1234` — which was never downloaded, so every
render died with "Executable doesn't exist" before rendering a frame. The cache
directory is now absent entirely (it held build 1217 back in July). Falls back to
`/usr/bin/chromium`: a full build, already driven by the SoundCloud transport, and
no ~150 MB pull into PLN's shared cache behind his back.
## 2. `--gl hw` never got hardware GL
The old comment claimed swiftshader manages ~7 fps and that `--gl hw` "asks for
the real integrated GPU via EGL. Falls back by simply measuring worse." It was
not falling back — it never left software. Instead of inferring the backend from
frame rate on a machine whose load is a variable, I asked WebGL what it resolved
to:
headless + --use-angle=swiftshader -> SwiftShader (Subzero)
headless + --use-gl=egl -> SwiftShader (Subzero) <- identical
HEADFUL -> Mesa Intel UHD (CML GT2)
Headless cannot reach this box's GPU whatever the flag. Which explains the
symptom exactly: landscape 1920x1080 captured 3.5 fps on swiftshader and 3.2 fps
on "hw", tripping the renderer's own under-5-fps guard both times — two numbers
that look like noise and were actually the same backend twice.
`--gl hw` now means HEADFUL. Measured after: **11.4 fps captured, page rendering
17** — 3.3x, comfortably past the guard. Note the bottleneck has moved: the page
now renders faster than the CDP screencast drains, so the next lever is the
capture path (frame encoding), not the GPU. Cost is a visible window for the
duration of each capture.
The July note warned against trusting those fps follow-ups because they were
measured at load average 12.5, and it was right to. But the fix was not a quieter
benchmark — it was asking a question that load cannot corrupt. Third time this
month a "the rig is broken" finding turned out to be the instrument.
Showing
Please
register
or
sign in
to comment