The GPU bottleneck nobody talks about is finally getting fixed

The second paper, DeMaVLA, isn't directly about physics acceleration but it shows why this matters. They're training vision-language-action models to fold laundry (yes, really, the holy grail task that's been "five years away" for twenty years now). The system was pre-trained on approximately 5,000 hours of real dual-arm demonstrations. That's a staggering amount of data, and you simply cannot process that volume if your physics computations are bottlenecked on CPU. They had to build an efficient action expert by pruning transformer layers while maintaining alignment with the VLM backbone. Clever, but also a sign of how much engineering effort goes into working around fundamental infrastructure problems.

The third paper from Matoses and colleagues takes a different approach: just run the whole physics simulation on GPU and use cross-entropy optimization to find good controller parameters. They're using Isaac Sim's parallelization to sample thousands of plan realizations simultaneously. The insight is that if you're going to need physics anyway (for contacts, dynamics, all the messy real-world stuff that analytical models ignore), you might as well make it fast enough to do Monte Carlo search over it.

Why this took so long

Honest answer? The robotics community has been weirdly conservative about infrastructure. Pinocchio works fine if you're running a single robot in a lab. Most academic roboticists until recently were doing exactly that. The shift to large-scale learning with thousands of parallel environments is relatively new, maybe five years old as a mainstream approach, and the tooling hasn't caught up.

There's also a cultural thing. Robotics people (and I say this with affection, some of my best sources are robotics people) tend to trust battle-tested C++ code over anything written in Python. They're not wrong to be cautious! Numerical bugs in dynamics code can make a robot arm swing through a wall or worse. But PyTorch's automatic differentiation is mature now, and the BARD authors show they match Pinocchio numerically. The paranoia is becoming counterproductive.

The other factor is that NVIDIA has been pushing Isaac Sim hard, and it does solve the GPU physics problem, but it's a walled garden. Not everyone wants to buy into that ecosystem. BARD being open source and pure PyTorch matters for adoption.

What this means practically

If you're training robot policies today, you should probably be looking at these tools. The BARD paper shows 8.5x speedup over Pinocchio and 2.0x over ADAM (another GPU dynamics library) when integrated into an Isaac Lab training pipeline for a quadruped with 4096 parallel environments. That's not a synthetic benchmark, that's a real training loop.

The DeMaVLA results are harder to evaluate because they don't release their full benchmark, but they claim competitive performance on RoboTwin and strong real-world results on household folding tasks. I remain skeptical of any laundry-folding claims until I see it work on my actual laundry pile, which includes fitted sheets and that one sweater with the weird buttons. But the architectural choices they made around efficiency suggest the community is taking throughput seriously now.

For the task and motion planning folks, the cross-entropy optimization paper is interesting because it suggests you can just brute-force search over physically realistic plans if your simulator is fast enough. That's a very different philosophy from the symbolic planning approaches that dominated TAMP for years. Whether it scales to longer-horizon tasks remains unclear, they only showed relatively short manipulation sequences.

The caveat

All three papers are preprints. The BARD code is open source (I checked, it's actually on GitHub, not vaporware), but I haven't run it myself. The 64x number is at batch size 4096, and your mileage will vary at smaller batches. The DeMaVLA model isn't released yet as far as I can tell. And the cross-entropy approach requires a good GPU physics simulator, which still means Isaac Sim for most people.

This is also, it's worth saying, infrastructure work. It doesn't solve the hard problems of robot learning, it just removes one bottleneck so researchers can iterate faster on the actual hard problems. But sometimes that's what progress looks like. You don't get breakthroughs if your training runs take a month instead of a day.

I've been watching robotics infrastructure slowly modernize for years now. It's not glamorous work and it doesn't get the press that humanoid demos do. But this is the stuff that actually determines whether the field moves forward or stays stuck in the lab. The kids building these tools are doing important work, even if their papers don't go viral on Twitter.

If you want to argue about any of this, my email's on the about page. I actually read it, unlike my Slack.

James Chen · 6 hours ago · 4 min