> ## Documentation Index
> Fetch the complete documentation index at: https://docs.eucaengine.com/llms.txt
> Use this file to discover all available pages before exploring further.

# The CPU/GPU split

> The architectural split that keeps appearance out of truth — authoritative state on the CPU, the GPU a read-only consumer. The one invariant, and the one caveat.

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](/evaluation/overview) without
the two contaminating each other.

## The split

* **CPU — everything authoritative:** the ECS scheduler and queries, physics solve (`rayon` islands),
  the [rule](/concepts/rules-as-data)/distribution evaluator, dataset extraction + digest, and the
  [`observe`/`peek`/`step`/`fork`](/concepts/query-verbs) 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`](/concepts/determinism) — 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.

<Warning>
  **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.
</Warning>

## Why the core is on the CPU

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. To be
precise about what the GPU can and cannot do:

1. The GPU is not hostile to `fork` — many parallel forked worlds is in fact its 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](/concepts/determinism)).
3. So the choice is about ergonomics and product axis — reading, cloning, and auditing being cheap on the
   CPU — not about the GPU being incapable.

## 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](/concepts/performance) for the measured
CPU numbers.

<Card title="Engine internals" icon="microchip" href="/concepts/engine-internals" horizontal>
  The ECS, renderer, and physics that sit on either side of the split.
</Card>