128 trajectories
—
—
PLAN. SAMPLE. MOVE.
Thousands of futures.
One next move.
Drive a robot with model predictive path integral control. Real rollouts, computed on your device — not a recording.
SAME SEEDED TRAJECTORIES / SAME HORIZON
GPU vs CPU · MPPI rollout costs
Preparing comparison…
CPU / JAVASCRIPT—
—
GPU / WEBGPU + TRANSFERS—
—
CPU MEDIAN / GPU MEDIAN—
—
Uses the selected trajectory count, current state and local target with seed 311. Both backends receive identical controls. Only rollout costs are timed: sampling, softmin, motion and drawing are excluded. GPU time includes uploads and all-cost readback; CPU time includes worker messages when supported (main-thread fallback otherwise). Three warmups, 15 alternating pairs, median/P10/P90. Costs must match within max(0.001 absolute, 0.1% relative), with identical collision classifications. GPU setup is excluded. This is WebGPU versus JavaScript, not CUDA versus native C++. CPU wins are shown; no GPU means CPU-only timing. Changes or hiding the tab cancel measurement.
MORE FUTURES / MEASURE THE TRADE-OFF
When does the GPU help?
Preparing experiments…
Rollout costs only: CPU worker round trip versus GPU upload/readback. Sampling, softmin, motion and drawing excluded.
Current pose and local target, fixed for the sweep. Each candidate has a 32-step horizon. CPU (blue) and GPU (mint) bars share one time scale; shorter is faster. Ratios are CPU / GPU: above 1 means GPU faster.
What do these results mean?
Run the sweep to see the measured trade-off. No result yet.
Descriptive results on this device, not a universal recommendation. Shares below describe the GPU path's host wall time, not isolated GPU execution or utilization. Blue = CPU sampling, mint = rollout call including uploads/readback, amber = CPU softmin. Shares use summed raw stage samples, not ratios of stage medians.
512 trajectories
—
—
2,048 trajectories
—
—
8,192 trajectories
—
—
128 trajectories
4,096 model steps maximum per call
CPU —
GPU —
CPU / GPU —
—
512 trajectories
16,384 model steps maximum per call
CPU —
GPU —
CPU / GPU —
—
2,048 trajectories
65,536 model steps maximum per call
CPU —
GPU —
CPU / GPU —
—
8,192 trajectories
262,144 model steps maximum per call
CPU —
GPU —
CPU / GPU —
—
Planning-stage medians
Complete-plan mode splits wall time into sampling, rollout evaluation and CPU softmin/update. Stage medians need not sum to the total median. Rollout-only mode does not measure these stages.
- 128 candidates
- —
- 512 candidates
- —
- 2,048 candidates
- —
- 8,192 candidates
- —
No measured crossover yet.
Both modes use three warmups and 15 alternating pairs at each count, excluding resource setup and compilation. In rollout-only mode, CPU worker round trips and GPU uploads/readback are timed; input generation is not. Every measured cost and collision classification is checked with the same tolerance as the single-count panel. JSON includes raw samples, input metadata and availability reasons. The first tested GPU win is not an interpolated crossover. Counts use fresh seed 311, but samples are not nested across counts. Invalid rollouts may stop before 32 steps. WebGPU versus JavaScript is not native CUDA versus C++.
Complete-plan mode recreates the same seed-311 planner with zero nominal controls for every call: a repeatable cold-start plan, not live warm-start latency. Sampling, cost evaluation and softmin/update are all timed; CPU allocation and GPU transfers are included. Setup, checking, drawing, motion and the command safety guard are excluded. CPU work runs on the main thread on both paths. Every measured cost, collision class, valid count and all 64 weighted control values must agree (control tolerance 0.001 m/s or rad/s), otherwise the affected ratio and crossover claim are suppressed. JSON preserves stage samples and measured control sequences. Arrivals and safe stops are checked separately below.
Does the robot actually arrive?
Separate, untimed closed-loop trials. Starts the selected built-in environment from its initial pose, not your edited live goal. Each backend uses seeds 311, 312 and 313, the same temperature and a 600-step limit. This can take tens of seconds. Small floating-point differences can lead to different later paths.
- CPU missions
- —
- GPU missions
- —
Arrival is distance below 0.30 m. Safe stops and timeouts count as failures, not successes. Motion is guarded at two substeps per command; minimum clearance is surface-to-robot margin at those checks, not a continuous collision proof. Three deterministic trials are not a general reliability estimate. CPU missions run on the main thread and yield between steps. No mission speed ratio is inferred. JSON includes seeds, settings, complete paths and classified outcomes. Missing GPU results remain unavailable. Changes, cancellation or hiding the tab discard partial reports.
SAME TIME BUDGET / DIFFERENT CANDIDATE COUNTS
What fits a planning deadline?
Calibrate complete plans, then compare three seeded missions at the largest tested count that fits each backend's P90 budget.
Preparing experiments…
Independent of the live count and sweep timing selector. Uses the selected built-in environment from its initial pose, first guide target and current temperature, not an edited goal. Calibration tests 128, 512, 2,048 and 8,192 candidates, with three warmups and 15 alternating complete-plan pairs. Counts whose costs or controls disagree are excluded. Each backend selects its largest tested count whose P90 fits; this is neither a continuous maximum nor a deadline guarantee. A backend with no fitting count is not tested.
No calibration yet.
CPU · calibrated count
—
—
GPU · calibrated count
—
—
Path colors: seed 311 blue, 312 mint, 313 amber. Circles mark the goal and recorded endpoints. Each independent mission uses the selected count throughout, with normal warm-start updates and a 600-step limit. Different counts mean different candidate sets, even with the same seeds and policy. Success is not assumed to improve with more samples.
Soft deadline, not real-time preemption: every mission plan times CPU sampling + cost evaluation + CPU softmin/update, including GPU transfers. An over-budget evaluator is allowed to finish, then its command is discarded and the mission stops before motion. Late durations remain in JSON and count as deadline stops, not safe arrivals. The main thread cannot forcibly interrupt JavaScript or GPU work. One evaluator warmup per trial excludes buffer setup. Checks, drawing, motion and between-step yields are untimed; simulated time advances only on accepted commands. Path length sums the two guarded model substep segments. Three trials do not establish reliability, continuous collision safety or a GPU-quality winner.
Same parallel idea. A browser-native backend.
Like the native CUDA controller, one GPU invocation evaluates one candidate trajectory. A softmin weights the sampled control sequences; the first command moves the robot, then the horizon shifts. Guide waypoints in the slalom scene provide a global route; MPPI is a local controller.
This is a simplified JavaScript / WGSL port, not CUDA running in a browser, not the full Nav2 controller and not a native performance benchmark. Sampling, weight reduction and drawing run on the CPU. WebGPU evaluates rollout costs; unsupported devices automatically use the JavaScript reference. No installs, external assets, telemetry, camera permissions or backend server.