SpectrumBuildOptions
Per-pipeline build-time knobs. All fields optional / default-valued for callers that don’t set them — leaving SpectrumBuildOptions unset matches the historic behaviour exactly.
Field |
Type |
Repeated |
Description |
precision |
Precision-vs-performance preference for integer fast paths. UNSPECIFIED / HIGH_FIDELITY: bit-exact float reference, default. FAST: integer fast paths with ≤2 LSB drift on 8-bit output; ~2× faster per-CPU-cycle on YUV↔RGB BT.709 UINT8 chains. BIT_EXACT: skip integer fast paths entirely. |
||
max_threads |
Max threads the pipeline may use at runtime. 0 = auto (default, current behaviour: parallel directives emitted, runtime uses all cores). Use this if you want the fastest possible per-frame latency and CPU budget is not the binding constraint. 1 = single-thread (no .parallel() directives in the schedule). Use for workflows that sustain target frame rate on one core and prefer lower CPU cost to lower latency — e.g. many concurrent low-load streams on one host. The kernel runs end-to-end on the calling thread with zero Halide worker-pool / queue / sync overhead. N >= 2 = cap (currently treated as auto for emission; runtime cap is a follow-up). CRITICAL: max_threads=1 is fundamentally different from taskset / cpuset pinning. Pinning binds the PROCESS to one CPU but the parallel directives still execute (workers spawn, queue/sync happens, all forced to share one core — 10-25× slower than the actual kernel). max_threads=1 makes the SCHEDULE itself serial so the runtime doesn’t engage at all. |