CPU and GPU state
Requires the gpu feature.
Syren can run selected systems on the GPU while the rest of the model runs on the CPU. The model stays the source of truth; the GPU holds mirrored copies of the component columns a GPU system needs.
GPU components
A component that a GPU system reads or writes must be GPU-safe: a
fixed-layout, plain-old-data type. Such a type implements GPUPod and is
registered with register_gpu_component instead of the plain registration, so
the framework knows it can be mirrored to a GPU buffer.
Mirroring and dispatch
For a GPU system, the framework mirrors the relevant component columns into GPU buffers, dispatches the compute shader over the archetypes, and reads results back when the CPU next needs them. Mirror buffers, parameter buffers, and bind groups are cached and invalidated by generation, so steady-state ticks reuse GPU resources rather than rebuilding them each tick.
GPU systems
A GPU system implements the GpuSystem trait: it names the resources it uses
and provides the shader and dispatch parameters. The scheduler treats it like any
other system for ordering — it participates in stages and channels — but
dispatches it to the device rather than running a CPU closure.
Visibility points
The CPU and GPU views of a column are synchronised at defined points: the scheduler boundary, and explicit sync or readback calls. Between those points a column may be resident on the GPU. Synchronising only at boundaries lets GPU dispatch avoid a blocking poll during the tick.
Building versus running
Enabling the gpu feature requires only that the wgpu crate compiles. Running a
GPU system requires a working graphics adapter. Where no adapter is available,
GPU execution is unavailable and the test suite reports a skip rather than
failing. A model that must run on machines without a GPU needs a CPU fallback
path.