Why persistent Blender processes matter
By Superluminal Engineering
See how keeping Blender warm and delivering outputs asynchronously can reduce repeated setup across an animation.
Published 2026-07-29 · Updated 2026-07-29
Publication status
Superluminal's source contains a per-job Blender server path and submission setting for using it. That verifies a mechanism seam; it does not quantify a speedup. This noindex protocol defines the controlled experiment required before publishing a claim about persistent Blender sessions or asynchronous pipeline work.
Why pipeline overhead matters
A render job includes more than GPU computation. Process startup, environment preparation, add-on installation, scene loading, dependency resolution, shader or kernel preparation, frame rendering, output writing, postprocessing, transfer, previews, retries, and final validation can all contribute to delivery time.
For a long Cycles frame, startup may be a small share. For a short EEVEE frame, the same fixed work may dominate. A single percentage cannot represent both. The study therefore reports phase time and GPU utilization by scene class rather than marketing a universal acceleration number.
Experiment cells
| Cell | Process state | Postprocess path | Current status |
|---|---|---|---|
| A | Cold start per frame or task | Synchronous | Pending |
| B | Warm persistent session | Synchronous | Pending |
| C | Cold start per frame or task | Asynchronous | Pending |
| D | Warm persistent session | Asynchronous | Pending |
Each cell needs repeated runs with the same scene, exact Blender build, device, settings, output, region, and load policy. Trial order should be randomized or balanced so cache warming and fleet conditions do not favor one treatment.
Where time goes beyond rendering
Startup, scene loading, output writes, uploads, and recovery still matter when frames are fast.
- Start · Process and environment startup
Measure cold process creation, environment readiness, add-on installation, and any warm reuse separately.
- Load · Scene load and dependency resolution
Record file open, linked data, shader compilation, kernels, and preparation with stable phase definitions.
- Render · Frame computation
Separate GPU-active render time from idle and CPU-only phases.
- Write · Output write and postprocess
Compare synchronous and asynchronous handling without hiding backpressure or failures.
- Deliver · Upload, preview, and final availability
Measure when a user can inspect the first output and retrieve the validated final result.
Required phase timeline
The event record must separate:
- assignment and environment readiness;
- process or server startup;
- scene open and dependency resolution;
- add-on activation;
- kernels, shaders, or other preparation;
- active rendering;
- output write;
- synchronous or asynchronous postprocess;
- preview availability;
- final upload and validation; and
- retry, resume, shutdown, or warm reuse.
GPU-active and GPU-idle periods should be visible. Asynchronous work is not “free”: the experiment must expose backpressure, concurrency limits, failure propagation, and the point at which an output is actually safe to use.
Scene classes and analysis
The suite should include fast frames, long frames, heavy scene load, substantial shader preparation, large outputs, memory pressure, and a seeded failure. Classroom by Christophe Seux can provide a CC0 baseline, but it is not the entire suite.
For each cell, publish sample count, median, tail latency, range, phase distributions, utilization, retries, failures, and uncertainty. The analysis should report absolute seconds as well as percentages; a large relative change can be operationally trivial when the baseline is tiny.
The Blender 5.1 benchmark supplies an end-to-end fixture boundary. The reliability protocol remains separate because a fast treatment that loses work is not an improvement.
Cold, warm, synchronous, and asynchronous runs
| Criterion | Process state | Postprocess path | Repeated trials | Status |
|---|---|---|---|---|
| Baseline A | Cold start per frame or task | Synchronous | Required | Pending |
| Treatment B | Warm persistent session | Synchronous | Required | Pending |
| Treatment C | Cold start per frame or task | Asynchronous | Required | Pending |
| Treatment D | Warm persistent session | Asynchronous | Required | Pending |
Release gate
The page becomes indexable only after A/B manifests, raw sanitized phase logs, scene and build hashes, analysis code, utilization charts, negative cases, and independent review are public. Any conclusion must say “for the published suite and conditions.” Until then, no universal startup reduction, throughput multiplier, or batching-free advantage is claimed.