ENGINEERING BLOG · 2026-08-05

What it takes to port a Physical AI stack to AMD

This guide follows one complete ROCm path from runtime and simulation assets to datasets, training, inference, closed-loop evaluation, and visual evidence. It distills the shared engineering contracts behind DISCOVERSE, RoboCasa365, DexJoCo, OpenPI, SmolVLA, Pi0.5, ACT, and GR00T.

ROCmMuJoCo / GenesisJAX / PyTorchClosed-loop evaluation
01 / ARCHITECTURE

One loop from pixels to physical outcomes

Physical AI repositories combine a physics engine, renderer, robot assets, datasets, a training framework, a policy runtime, and a controller. A complete AMD port keeps their semantics aligned: the model receives the intended images and state, produces actions in the trained scale and order, and the simulator executes them at the correct cadence.

Runtime and deviceScenes and assetsExpert dataTraining and checkpointsPolicy bridgeFixed evaluation
The integration contract

Task definition, observation schema, action schema, control frequency, checkpoint identity, seeds, result JSON, and media are versioned together. That contract turns a working experiment into a reusable system.

02 / METHOD

Six layers with explicit acceptance gates

Each layer has a concrete input, executable check, and artifact. The same sequence works for a new simulator, robot, or policy without coupling every issue into one environment.

01

Runtime

Pin ROCm, HIP, Python, PyTorch or JAX, simulator, and plugin versions; record the detected GPU backend.

02

Simulation

Run official reset, step, and render calls headlessly, then export a stable MP4 from the original scene.

03

Data

Audit observation and action dimensions, temporal order, episode boundaries, padding, and normalization statistics.

04

Training

Preserve configuration, metrics, checkpoints, hashes, and resume semantics under one output directory.

05

Inference

Bind the checkpoint to its tokenizer, stats, camera map, action chunk, controller, and execution frequency.

06

Evaluation

Use fixed tasks, seeds, process topology, full denominators, videos, result JSON, and SHA-256 manifests.

03 / CASE STUDY

DISCOVERSE: expert trajectories, HD replay, and 3DGS

DISCOVERSE is the broadest simulator workstream in the suite. MuJoCo tasks, AIRBOT and MMK2 assets, expert trajectories, policy entry points, ROS2, LiDAR, Gaussian Splatting, and MP4 export share one reproducible AMD integration path.

18 / 18core runtime gates
12 / 12AIRBOT tasks
8 / 8MMK2 tasks
31 / 31strict bridge replay

3.1 Reachable expert motion

The block_bridge_place trajectory exposed an interaction between inverse-kinematics reachability, support collisions, and discontinuous stage targets. The repaired workflow checks end-effector reachability first, support clearance second, and only then freezes the trajectory and task definition. The resulting strict replay completes 31 of 31 stages.

3.2 Headless, multi-view video

MuJoCo offscreen rendering and platform-specific headless backends generate native RGB frames before FFmpeg encoding. Four MMK2 tasks are captured at 1920x1080 from synchronized views so end-effector motion, object state, and scene changes remain readable.

3.3 Gaussian Splatting on ROCm

The isolated ROCm renderer loads 1,334,537 RM2 points and 1,026,855 SkyRover points, renders non-empty 640x360 frames, and drives dynamic Franka and UR5e replay. Separating the simulator and renderer runtimes keeps their graphics and ML dependencies stable.

source local_tools/activate_amd_runtime.sh
python -c "import torch, gaussian_renderer; print(torch.__version__, torch.version.hip)"
python local_tools/verify_gaussian_renderer.py \
  --robot rm2 --output results/gaussian/rm2.png \
  --width 640 --height 360
04 / CASE STUDY

RoboCasa365: assets, policy protocols, and four-view replay

The RoboCasa365 workstream brings the complete official asset archive, environment registration, MuJoCo rendering, Pi0.5 JAX inference, GR00T inference, and a shared 16-task protocol onto AMD 395. The same run produces per-task statistics, aggregate JSON, and synchronized center, left, right, and wrist videos.

WorkstreamProtocolVisual outputArtifacts
Pi0.516 tasks × 50Multi-task closed-loop replayJSON · MP4 · SHA-256
GR00T16 tasks × 50Household manipulationJSON · MP4 · SHA-256
Long-horizon gallery4 tasks × 10Steam, restock, pack, and coffee tasksFour-view task films

4.1 Asset integrity before policy inference

The asset archive is verified by byte size, checksum, extracted file count, scene reset, and render output. This makes environment identity an explicit part of every policy result.

4.2 One run, two readable outputs

The fixed protocol supports model comparison; the four-view gallery explains the behavior. Both originate from the same model and environment run, and the result index connects them by task and seed.

05 / CASE STUDY

ROCm JAX and Pi0.5: from backend test to robot actions

The native environment follows AMD's official ROCm JAX route: Python 3.12, ROCm 7.14, JAX and JAXlib 0.10.0, and a rocm:0 backend on gfx1151. Matrix, convolution, attention, Orbax restore, tokenizer, normalization, vision input, action decoding, and MuJoCo execution are validated in sequence.

Why the full stack matters

A visible GPU backend establishes device access. A robot policy additionally depends on parameter-tree compatibility, tokenizer and normalization identity, camera tensors, attention kernels, action decoding, and simulator timing.

5.1 Version the runtime as one unit

ROCm, JAX, jaxlib, the ROCm plugin, PJRT, and model code move together. This resolves target-GFX kernels, shared-memory pressure, convolution compilation, and checkpoint metadata at their actual interface boundaries.

5.2 Validate one task, then the multi-task protocol

  1. Restore Orbax parameters, tokenizer, and normalization statistics.
  2. Run one diagnostic task with saved observations, actions, and MP4.
  3. Freeze the model and environment identity in the run manifest.
  4. Run the official task set and aggregate results without changing the protocol.
JAX 0.10native ROCm runtime
16 × 50RoboCasa365 archive
11DexJoCo tasks
4-viewtask replay
06 / POLICY WORKFLOWS

Training, checkpoints, and closed-loop evaluation

Every Embodied provides native notebooks for SmolVLA, Pi0, and ACT training, protected fine-tuning, evaluation, and video generation. RoboWits adds the W7900 ACT 100k route with checkpoint restore, HD replay, task evaluation, and a final hash manifest.

Diagnostics follow the task stages

Approach, contact, grasp, lift, transport, place, release, and recovery statistics map a task result back to data coverage, action bridging, chunk execution, cameras, and normalization.

07 / ENGINEERING PATTERNS

Nine recurring interfaces in Physical AI ports

01 · GPU IDENTITY

ROCm through framework APIs

Record HIP version, rocminfo, GPU model, backend, and measured memory use together.

02 · HEADLESS

Offscreen rendering

Select EGL, OSMesa, or the simulator's native offscreen path, then validate frames and encoding.

03 · KERNELS

Target-GFX coverage

Exercise matrix, convolution, attention, plugin, and PJRT paths on the actual GPU architecture.

04 · ACTIONS

Chunk execution

Chunk length, overlap, temporal ensembling, joint convention, gripper encoding, and control rate define execution.

05 · NORMALIZATION

Checkpoint statistics

Archive state dimensions, action scales, camera shape, color order, and normalization with the checkpoint.

06 · CLOSED LOOP

Accumulated control error

Action traces and stage metrics reveal where local prediction error becomes a physical task outcome.

07 · ASSETS

Scene identity

Version official assets, licenses, BlenderKit references, and task distributions with the environment.

08 · TOPOLOGY

Repeatable evaluation

Fix seeds, process count, cold or warm startup, worker reuse, and output layout.

09 · STORAGE

PVC and restart recovery

Keep datasets, checkpoints, manifests, environment records, and resume commands on persistent storage.

08 / REPRODUCTION

Reproduce the smallest complete loop first

Start with runtime identity, official scene reset, one rendered episode, and artifact validation. Then run training or the fixed evaluation with the same environment and output contract.

export PROJECT_ROOT=/path/to/radeon-physical-ai-evidence-suite
export DATA_ROOT=/path/to/data

# 1. Verify the AMD runtime
python -c "import torch; print(torch.__version__, torch.version.hip, torch.cuda.is_available())"
rocminfo | head -n 30

# 2. Run an official reset/render and save an MP4
python scripts/robocasa_amd_smoke.py --output results/smoke

# 3. Validate the intended checkpoint and evidence files
sha256sum -c SHA256SUMS
ffprobe -v error -show_streams results/formal/success.mp4

# 4. Run the fixed task and seed protocol
python scripts/evaluate_official.py \
  --checkpoint /path/to/checkpoint \
  --seeds 0 1 2 3 4 \
  --save-video --output results/formal
GateArtifactFollowing gate
import + backendPinned dependencies and AMD device recordreset / render
reset / renderFrame and MP4 with scene identityPolicy load
Policy loadCheckpoint, tokenizer, stats, and manifestClosed loop
Closed loopActions, stages, videos, and result JSONFixed protocol
Fixed protocolAggregate metrics and SHA-256Publish
09 / PUBLICATION

A review path from result to reproduction

The public package organizes each workstream around five linked objects: source, report, model or checkpoint manifest, evaluation data, and video. A reviewer can start with the film, open the task result, verify the artifact hash, and continue into the exact environment and command.

  • Sourceversioned adapters, launchers, validators, and notebooks
  • RuntimeAMD GPU, ROCm, framework, simulator, and dependency matrix
  • Resultsfixed protocol, aggregate metrics, stage statistics, and task videos
  • Integritytagged release, manifests, and SHA-256 verification