PUBLIC - screenshare ready

FeatherPGS (FPGS) - post-merge rebench

FPGS vs current MJWarp vs PhysX · matched-fidelity protocol · RTX PRO 6000 Blackwell (96 GB) · fpgs-main @ 7efc42fd · 2026-07-29

Builds: solver-core #1259 (21/21) · dense-contact #1258 (39/39) · fair rerun #1271 in flight · p13 = external partner FeatherPGS collision path

The honest headline. FPGS still beats PhysX across every RL scene (franka_lift 2.7-4.6x, g1_flat 1.8-2.8x). But this rerun tells a more nuanced - and more credible - story than "17x across the board." Current MJWarp genuinely caught up on the RL scenes (it now leads FPGS on g1_flat by ~15-25%, and is the fastest backend on p12/h1_tabletop below its memory wall). FPGS's decisive, unambiguous win is the dense mesh-pile regime: 10-16x over MJWarp on cube piles, and ~17x over everything on p13 GraspNet object-rain - the one scene where MJWarp OOMs and PhysX hits an engine ceiling, leaving FPGS the only backend still standing.

1. RL scenes solver-core build #1259 · franka_lift + g1_flat

Throughput is env-fps (env-frames per second, higher is better) versus parallel environments. franka_lift is FPGS vs PhysX only (MJWarp×franka is not wired in CI, as in every prior benchmark); g1_flat is the full 3-way.

RL scene throughput — franka_lift: FPGS leads PhysX 4.6x -> 2.7x as envs scale. g1_flat: FPGS is 1.8-2.8x over PhysX, but current MJWarp now sits ~15-25% above FPGS at every rung.

FPGS beats PhysX everywhere - franka 4.59x / 3.36x / 2.74x at 1k/4k/8k; g1_flat 2.81x / 2.83x / 2.01x / 1.79x. Consistent with the prior (build-998) verdict.
New and real: current MJWarp now beats FPGS on g1_flat by ~15-25% at every rung (mjw3102 image + current pin). MJWarp has genuinely improved - we state this plainly.

2. Dense-contact piles dense-contact build #1258 · p10 / p11 / p12

Cube-pile probes (p10, p11) and the H1 confined-tabletop pile (p12). Throughput is env-fps; the second figure is settled per-step wall time (log-y, lower is better).

Dense-contact throughput — Cube piles (p10/p11): FPGS is 10-16x over MJWarp; MJWarp OOMs at 16384. p12: current MJWarp is the fastest backend below its OOM wall. Dotted line = FPGS's fair-config numbers from the prior report baseline (#1252) - #1258's solid FPGS line is pessimistic (see caveat).

Dense-contact settled step time — Settled step time (ms, log-y). On cube piles MJWarp is ~15-40x slower per step; on p12 MJWarp is fastest until it OOMs at 16384 where FPGS and PhysX keep scaling.

Cube piles (p10/p11): FPGS is 10.8-16.1x over MJWarp; MJWarp is 10-410 ms/step and OOMs at 16384. FPGS trails PhysX here on raw speed - but see the fairness caveat (and the fair-config dotted line closes much of that gap).
p12 / h1_tabletop: the original hypothesis was "MJWarp falls apart on the high-DoF scene." Refuted on speed - current MJWarp is the fastest backend on p12 below 16384 (684k env-fps @4096). Confirmed only as a memory wall: MJWarp OOMs at 16384 while FPGS and PhysX scale on.

Fairness caveat - bake this in. Build #1258's FPGS columns are pessimistic: they omitted the fair FEATHER_PGS_VELOCITY_LIMIT_ACTIVATION_FRACTION=0.5 config that the report baseline (#1252) used (~1.3-1.4x on FPGS). MJWarp and PhysX settings were identical across both builds, so their columns stand; the FPGS solid lines will lift when build #1271 (the fair rerun, in flight) lands. The dotted "fair, prior #1252" line shows where FPGS actually sits.

3. p13 - GraspNet object-rain the killer result · TOP PRIORITY

p13 drops 60 GraspNet meshes onto a Franka - a dense, irregular mesh-on-mesh pile. This is the regime FPGS's collision path was built for. The numbers below are the prior grogu env-scaling sweep (A6000, 48 GB); the post-merge Blackwell rerun is wired and validated end-to-end - it is one asset-staging step away (GraspNet USDs are not yet on the CI cluster).

p13 throughput and memory wall — Left: throughput (env-steps/s, log-y). FPGS climbs to ~9,500 while PhysX and MJWarp plateau at ~500-800 - **~17x** - and FPGS is the only backend that survives 8192 envs. Right: the three different walls at 8192 - PhysX's uint32 collision-stack ceiling, MJWarp's ~36 GB convex-narrowphase (EPA) allocation, and FPGS running clean at ~40 GB.

The one-liner. On p13, FPGS is ~17x faster than both PhysX and MJWarp at scale (16.7-19.2x at 2048-4096), and it is the only backend that runs 8192 envs at all - MJWarp OOMs on a single ~36 GB EPA allocation in the convex narrowphase, and PhysX hits a true engine ceiling (its collision stack is uint32-capped at 4.29 GB; it needs ~7.6 GB there). Three backends, three different walls - FPGS has none.

Mechanism - why MJWarp collapses here

MJWarp gets no fast-collision win on p13. It peaks at ~567 env-steps/s (about PhysX's 568), then degrades to ~221 at 2048-4096 as the mesh count bites, and dies at 8192. Its time and its memory both go into the convex narrowphase (EPA) - that is the slow path and the OOM wall.
FPGS's SDF/mesh collision path is cheap, so its budget goes to the solve - which is why it both runs faster and scales in memory (rawmesh and sdf variants both reach 8192).
Fidelity holds too: FPGS stays ~90 mm worst-case penetration at every env count; PhysX default collapses at 4096 (3,625 mm, dropped contacts) and needs a heavy hi-capacity preset to recover; MJWarp is faithful but on the wrong side of the memory wall.

Status of the fresh p13 numbers. The table above is the prior grogu sweep (A5000/A6000). The post-merge rerun is fully wired and validated (CI plan 46/46, canary reached the exact asset-load step) but blocked on staging the GraspNet USDs to the CI cluster - fresh Blackwell numbers pending. On the 96 GB Blackwell cards every wall may move up, which only strengthens the figure (FPGS could post 16384). Per-stage / per-kernel timing to prove the EPA mechanism is a secondary flesh-out (feasible via nsys/nvtx on a small run; not blocking today).

4. Bottom line

FPGS beats PhysX on every RL scene (2.7-4.6x franka, 1.8-2.8x g1).
Current MJWarp is real competition on the RL + mid-range dense scenes - it leads FPGS on g1_flat and on p12 below its memory wall. We verified this deliberately; it makes the rest credible.
FPGS owns the dense mesh-pile + memory-scaling regime: 10-16x over MJWarp on cube piles, ~17x over everything on p13, and the only backend that keeps running when MJWarp OOMs and PhysX hits its engine ceiling.
Two open items: fair-config dense rerun (#1271, in flight) to lift FPGS's p10/p11/p12 lines; fresh p13 Blackwell numbers (asset-staging away, wiring done).

FPGS post-merge rebench · fpgs-main @ 7efc42fd · RTX PRO 6000 Blackwell 96 GB · matched-fidelity protocol (FPGS substeps=1 / pgs_iter=2 / omega=1.7; MJWarp iter=100 / ls=50; PhysX rigid-pos-iter=16). Solver-core #1259, dense-contact #1258; fair rerun #1271 pending; p13 = prior grogu sweep, fresh rerun asset-gated. Public - screenshare ready.