End-to-end RL training benchmark: Newton vs PhysX in Isaac Lab (Go2 locomotion), with throughput scaling, per-process VRAM, and a dynamics-equivalence probe

[yusufdxb]

Hi all - I ran a controlled comparison of the Newton (MuJoCo-Warp) and PhysX backends in Isaac Lab 3.0 on the stock Isaac-Velocity-Flat-Unitree-Go2-v0 task, end-to-end through RL training, on a consumer Blackwell-architecture NVIDIA GPU. I'm sharing it because the public numbers I could find are solver-level (the asv suite, the MJX comparisons, one dexterous-manipulation PhysX datapoint), and I couldn't find an end-to-end training comparison, VRAM data, or consumer-GPU coverage anywhere. This seems relevant to #2946 (benchmark coverage) and the RL-iteration discussion in #3257.

Full methodology, scripts, and raw artifacts: https://github.com/yusufdxb/physx-newton-bench (tagged newton-physics). Every number below traces to an on-disk artifact there.

Setup

• Isaac Lab 3.0.0 (a4a7602f), Newton 1.0.0, Warp 1.12.0, mujoco-warp 3.5.0.2, rsl-rl 5.0.1, torch 2.10.0+cu128, driver 570.211.01 / CUDA 12.8 (full pip freeze + env capture in the repo)
• Task: Isaac-Velocity-Flat-Unitree-Go2-v0 (manager-based, rsl_rl PPO, stock config, 300 iterations)
• Backend selected purely via the Hydra presets=physx / presets=newton token; the resolved per-run config is dumped to disk and diffed: only the physics-manager block differs
• Hardware: one consumer Blackwell-architecture NVIDIA GPU (same machine, otherwise idle)
• Newton solver config is the stock one shipped in the task (MJWarpSolverCfg(njmax=65, nconmax=35, cone="pyramidal", integrator="implicitfast"), 1 substep): deliberately NOT retuned; this is a stock-vs-stock comparison

1. Throughput scaling (pure stepping, zero-action, warmup excluded)

10 independently timed repeats per point, mean ± std env-steps/s, VRAM measured per-PID (nvidia-smi --query-compute-apps), not whole-GPU:

num_envs	PhysX steps/s	Newton steps/s	ratio	PhysX VRAM (MiB)	Newton VRAM (MiB)
256	36,877 ± 2,829	82,281 ± 10,609	2.23x	2451	304
1024	136,708 ± 9,811	282,463 ± 33,819	2.07x	2723	368
2048	247,140 ± 14,538	477,471 ± 49,831	1.93x	3019	434
4096	371,229 ± 18,567	732,796 ± 62,073	1.97x	3553	566

Methodology notes that matter for reading the table:

• "Zero-action" here means the DCMotor PD holds the default standing pose (the task's action term offsets default joint positions): the probe steps a standing robot (~4 foot contacts/env, far from nconmax saturation), not a collapsed one.
• Both backends integrate one physics step per sim.dt=0.005 (Newton num_substeps: 1; PhysX has no substep multiplier in this config): the resolved per-run configs are committed in the repo, and the two agent.yaml are identical up to run_name.
• All envs start together, so the synchronized episode-timeout reset lands in the last timed block for both backends (~15–25% dip, visible in the raw JSONs, kept in the stats). The first block shows no JIT slowdown.

Two things stood out:

• End-to-end training throughput is a smaller gap than pure stepping. Over full PPO training runs (n=10 seeds each), Newton averaged 241,608 ± 2,195 total fps vs PhysX 147,187 ± 2,203: 1.64x, vs ~2x for pure stepping: because the learning side is backend-independent. Both numbers are real; which one you experience depends on how much of your loop is sim.
• The memory curve is a big consumer-GPU story, with a fairness caveat. Newton's per-process footprint grows 304→566 MiB while quadrupling envs; PhysX grows 2451→3553 MiB; during training the gap was 617 vs 3247 MiB peak (5.3x). But this is stock-config footprint, not intrinsic engine efficiency: the stock PhysX arm pre-allocates a large patch pool (gpu_max_rigid_patch_count = 10·2¹⁵) while stock Newton sizes tight per-env buffers (njmax=65, nconmax=35). It is what a stock-config user experiences on this task; a tuned-buffer comparison would narrow it.

2. Learning behavior (n=10 seeds per backend, identical stock config)

Honest split, because the two views disagree:

• Vs wall-clock, Newton is ahead at every equal time budget within its 61 s training window: cheaper iterations compound.
• Vs iteration, PhysX converges higher on this PhysX-tuned asset: final reward IQM 30.36 [28.71, 31.09] vs 19.48 [16.77, 22.36] at 300 iters (95% stratified-bootstrap CIs per rliable; plain mean±std 29.78 ± 2.65 vs 19.63 ± 3.45 says the same thing).
• I want to be careful with framing: this is NOT "Newton learns worse." The asset, rewards, and stock solver settings were all tuned under PhysX, and the probe below shows the two backends genuinely integrate different dynamics: the two policy populations are optimizing different landscapes. A fair asymptotic comparison needs per-backend tuning, which I deliberately did not do.

3. Open-loop dynamics-equivalence probe (the part I found most interesting)

Same asset, num_envs=1, all randomization off, identical initial state, identical open-loop action tape, 6 s horizon, recorded under both backends (twice each):

• Both backends replayed deterministically across our repeats (two recordings per backend): same-backend divergence is exactly 0.0 m / 0.0 rad, so within this experiment all cross-backend divergence is attributable to the backend, not RNG or the harness.
• Cross-backend: base position diverges to 0.41 m and orientation to 25° over 6 s; mean joint RMSE 0.176 rad; 5 cm crossed at 1.72 s.
• Systematic, not just chaotic: during a 1 s zero-action hold on the default pose, joints already disagree by 0.118 rad: before any contact-driven amplification.
• Migration footgun: joint/body ordering differs between backends on the same asset (PhysX joint-type-major: FL_hip, FR_hip, RL_hip, …; Newton leg-major: FL_hip, FL_thigh, FL_calf, …). Feeding one backend's action vector to the other without remapping silently commands different physical joints. Worth knowing about when doing sim2sim by hand, alongside Isaac Lab's newton_to_physx_go2.yaml tooling.
• Joint-drive gain representation differs at the data level, but effective PD is identical. With the Go2's DCMotorCfg(stiffness=25, damping=0.5) (explicit Python-side PD applied as effort), the PhysX data path reports physics-level joint stiffness/damping 0/0 while Newton reports 25/0.5. I traced this through Isaac Lab and MJWarp source and confirmed empirically on the live model (mjw_model.nu == 0, all 12 joints JointTargetMode.EFFORT): MJWarp builds zero PD actuators, so the echoed gains are never consumed, and the comparison above is a true single-PD-vs-single-PD comparison on both backends. The write-order issue in Isaac Lab's Newton articulation path that causes the misleading echo (and that becomes genuine double-PD for assets with nonzero USD drive gains) turned out to be already reported as [Bug Report] Newton backend re-enables joint target stiffness/damping for explicit actuators, causing different rest pose from PhysX isaac-sim/IsaacLab#5806; I've added the full trace and the live nu==0 measurement there.

Consequence for RL users: the reward gap in section 2 is expected given measurably different contact dynamics: cross-backend transfer of a trained policy can't be assumed without re-validation.

Caveats

Single task (Go2 flat velocity), single robot, single GPU. Stock solver settings on both sides: no per-backend tuning attempted. Pure-step probe uses zero actions. One action tape / one dt in the dynamics probe; late-time divergence mixes the systematic difference with deterministic sensitive-dependence amplification through contact (the clean signal is the 0.118 rad settle-phase number). The Newton backend in Isaac Lab 3.0 is experimental, so these numbers will move. No sim-to-real claims.

Happy to run additional configs if useful for #2946, and glad to be corrected on any of the methodology.