The capture harness uses the graphics card that was there all along
`launch()` asks for `--use-angle=vulkan` and gets the Radeon RX 6700 XT. On the real film loop at 1440x900 that is 7.56 s a frame to 0.47, and about twelve cores pegged down to less than one. A 180-frame film goes from twenty-two minutes to ninety seconds; the three shipped reels go from over an hour to four minutes. The SwiftShader flag was inherited from the share-card script and its comment said "a box with no display and no GPU". Half of that was never true. The card has been in this machine the whole time, with the amdgpu driver and a working RADV ICD, and Chrome reaches it with **no display server at all** — no DISPLAY, no XDG_RUNTIME_DIR, nothing but read access to /dev/dri/renderD128, which group `render` already grants. So the portability the flag was protecting is intact: this still runs over ssh and under cron. Naming the backend is the whole trick, and most of the plausible spellings are traps. `--use-angle=gl`, `--use-gl=egl`, `--use-gl=desktop`, `--enable-features=Vulkan` and passing no GL flags at all were each measured on this box, and all five land on SwiftShader while reporting success. Only `--use-angle=vulkan` and `--use-angle=gl-egl` reach the card. So `launch()` verifies instead of assuming. `--use-angle=vulkan` is a demand, not a preference: with the driver hidden it yields no WebGL context at all rather than falling back, the boot curtain never lifts, and the caller sits in `waitForFunction` until a three-minute timeout before failing with something that looks nothing like "there is no GPU here". Reading `UNMASKED_RENDERER_WEBGL` once per run costs about half a second and turns that into a printed line and a slow, correct render. Both branches are tested; the sabotaged one was verified with `VK_LOADER_DRIVERS_DISABLE`. The pictures are the same pictures: mean absolute difference of half a level out of 255, confined to MSAA edges and to cloud shadow that already drifts between any two runs of the same renderer. Also corrects every comment across the four scripts that asserted three frames a second or twenty-two minutes a reel. Those were true when written and are not now, and the `reducedMotion` rationale in two of them was resting on the number: the real reason a chapter flight cannot be waited out is that it is ~40 frames however fast they are drawn, which was twenty seconds under software GL and is a shorter race on the GPU — still a race. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -27,9 +27,8 @@
|
||||
* ### Why the clock is stepped and not simply left running
|
||||
*
|
||||
* Real-time capture is not available on this box and would be the wrong idea
|
||||
* anyway. SwiftShader draws about three frames a second with no GPU, so a
|
||||
* screen recording would be a slideshow; and a sunset takes an hour, which is
|
||||
* not a length of video anybody watches. So the film is rendered offline the
|
||||
* anyway. A sunset takes an hour, which is not a length of video anybody
|
||||
* watches, and the capture loop screenshots far slower than it renders. So the film is rendered offline the
|
||||
* way films always have been: set the clock, let the frame settle, expose,
|
||||
* advance. The output is smooth 30 fps regardless of what the renderer managed
|
||||
* while it was being photographed.
|
||||
@@ -188,10 +187,10 @@ const only = flag("only")?.split(",").map((s) => s.trim());
|
||||
/**
|
||||
* Override the frame count for a rough cut.
|
||||
*
|
||||
* Filming costs about seven seconds a frame at 1440x900 on this box, so a
|
||||
* 180-frame film is some twenty-two minutes. `--frames 24` is three, and it is
|
||||
* the cheapest possible way to discover that a camera is pointed at the wrong
|
||||
* thing. A rough cut also skips the site, because a 24-frame stutter is not
|
||||
* Filming costs about half a second a frame at 1440x900 on the GPU, so a
|
||||
* 180-frame film is a minute and a half; on the software fallback it is seven
|
||||
* seconds a frame and twenty-two minutes. `--frames 24` is the cheapest
|
||||
* possible way to discover that a camera is pointed at the wrong thing. A rough cut also skips the site, because a 24-frame stutter is not
|
||||
* something to publish by accident.
|
||||
*/
|
||||
const frameOverride = flag("frames") ? Number(flag("frames")) : null;
|
||||
@@ -202,10 +201,10 @@ const manifestOnly = process.argv.includes("--manifest-only");
|
||||
/**
|
||||
* Publish an existing render directory to the site instead of shooting a new one.
|
||||
*
|
||||
* Filming is twenty-two minutes a reel, so there has to be a way to put reels
|
||||
* that already exist in front of the site without paying that again — otherwise
|
||||
* the answer to "how did those files get there" becomes `cp`, and a hand-copied
|
||||
* artefact is exactly the thing this pipeline exists to not have.
|
||||
* There has to be a way to put reels that already exist in front of the site
|
||||
* without re-shooting them — otherwise the answer to "how did those files get
|
||||
* there" becomes `cp`, and a hand-copied artefact is exactly the thing this
|
||||
* pipeline exists to not have.
|
||||
*/
|
||||
const publishFrom = flag("publish");
|
||||
const wanted = only ? FILMS.filter((f) => only.includes(f.id)) : FILMS;
|
||||
@@ -266,7 +265,7 @@ async function expose(page, instant) {
|
||||
await page.waitForTimeout(260);
|
||||
// ...and then two straddled frames, so what is on screen is what we just asked
|
||||
// for rather than the one before it. A `waitForTimeout` alone cannot promise
|
||||
// that at three frames a second.
|
||||
// that when the renderer is slower than the loop asking for frames.
|
||||
await page.evaluate(
|
||||
() => new Promise((r) => requestAnimationFrame(() => requestAnimationFrame(r))),
|
||||
);
|
||||
@@ -423,8 +422,8 @@ async function writeManifest() {
|
||||
* Copy a render directory to the site, then rewrite the manifest.
|
||||
*
|
||||
* A film that is not in `fromDir` but is already published is **left alone**
|
||||
* rather than treated as an error. Reels cost twenty-two minutes each, so a
|
||||
* one-reel render is the normal way to add or replace one, and demanding that
|
||||
* rather than treated as an error. A one-reel render is the normal way to add
|
||||
* or replace one, and demanding that
|
||||
* every reel be present in the same directory would mean re-shooting the whole
|
||||
* set to change any of it. What is not tolerated is a film that exists in
|
||||
* neither place: the manifest is about to name it, so that is a hard failure
|
||||
|
||||
Reference in New Issue
Block a user