Skip to main content
Euca’s authoritative world lives on the CPU; the GPU is a strictly read-only consumer. This split is what lets the engine be both a great renderer and an exact answer key without the two contaminating each other.

​
The split

  • CPU — everything authoritative: the ECS scheduler and queries, physics solve (rayon islands), the rule/distribution evaluator, dataset extraction + digest, and the observe/peek/step/fork loop. This is the hashed, forkable source of truth.
  • GPU — euca-render: consumes CPU state to produce frames (and the dataset’s ground-truth segmentation + depth channels). It reads state; it never writes it.

​
The one invariant

No GPU → authoritative-state write edge. CPU state is the source of truth (state → render → readback); the GPU never mutates it.
This is what makes two AI-generated visual skins of the same world produce a byte-identical state_digest — appearance is decoupled from truth by construction, not by convention. A single canonical seeded RNG (the only sanctioned stream) gives bit-identical replay within a run, which is what makes peek == step and fork coherent.
The caveat: this holds with observations off (the default). The moment a vision-conditioned policy runs (pixels → action → next state), the GPU render enters the causal loop and the leaf is no longer pure. The property is config-dependent — true for state-based control and data generation, not for pixel-conditioned control.

​
Why CPU for the core (the honest reason)

Not because the GPU is hostile — it isn’t. The product axis is exact, auditable, forkable, queryable ground truth, and the white-box ergonomics that requires (read any per-step quantity; clone the world mid-episode where the schedule already lives) are native and cheap on a CPU engine. Three myths worth retiring:
  1. The GPU is not hostile to fork — many parallel forked worlds is the GPU’s best case.
  2. A GPU can be made deterministic within a run on one machine; only cross-hardware bit-reproducibility is genuinely hard (and Euca doesn’t claim it).
  3. So “we’re on CPU because the GPU can’t” is false — the reason is ergonomics and product axis, not impossibility.

​
Throughput reality

In a benchmark run the model being graded dominates, not the simulator, and data generation is embarrassingly parallel across seeds. The one genuine future exposure is on-policy RL / live control at scale — answered by a separate, optional GPU-batched bulk-rollout path (rollouts you never peek into), never a rewrite of the authoritative core. See Performance for the measured CPU numbers.

Engine internals

The ECS, renderer, and physics that sit on either side of the split.