MuJoCo Warp for NVIDIA GPU Physics Simulation

Why MuJoCo Warp targets parallel robotics workloads

MuJoCo Warp, or MJWarp, addresses the cost of simulating robotics models when researchers need higher throughput on NVIDIA GPUs. The README describes it as a GPU-accelerated version of MuJoCo and positions it for robotics research involving rigid bodies, contacts, soft bodies, cloth, and signed distance fields. Its central audience is therefore engineers and researchers who repeatedly evaluate controls, motions, contacts, or learned policies rather than users who need a single small simulation on a laptop.

The package is not a new modeling format or a visual editor. It remains tied to MuJoCo, depends on `mujoco>=3.13.0`, and presents an API intended to work as a drop-in replacement in many cases. That distinction matters. Existing MuJoCo scenes can remain the starting point while simulation execution moves toward a GPU-oriented path. The repository includes benchmark scenes such as the Unitree G1 humanoid, MyoArm, ALOHA manipulation tasks, humanoid models, cloth, heightfields, pots, and signed distance fields.

An NVIDIA GPU is required for fast simulation, but the README explicitly says that CPU execution is supported for development and debugging. This makes the hardware requirement a performance boundary rather than an absolute statement that the package cannot run without an NVIDIA device. It also means an adoption decision should separate functional access from the throughput that motivates a GPU implementation.

MuJoCo behavior and documented compatibility boundaries

MJWarp follows MuJoCo's API closely, but the README is explicit that compatibility is not complete. The `IMPLICITFAST` midpoint integrator feature is unsupported. The `PGS` solver is not yet supported, and `noslip` is not supported with the `discrete` integrator. Actuator and sensor types based on `PLUGIN` are also unavailable.

Flex support is labeled experimental, with incomplete implementation and optimization. This is a meaningful limitation for projects centered on deformable structures. Although MJWarp lists soft bodies and cloth among its supported simulation areas, that broad description does not imply full parity for every Flex feature. A model can use a category named in the examples while still depending on a particular solver, integrator, constraint, actuator, sensor, or optimization path that falls outside the current implementation.

Differentiability through Warp is not yet available either. The README points to issue `#500` for progress, but it does not describe differentiability as ready. Researchers whose workflow requires gradients directly from the simulation should therefore treat that capability as unavailable rather than infer it from NVIDIA Warp support.

These exclusions should be checked against the actual XML model, Python interface calls, solver settings, and downstream training code. API similarity alone cannot establish behavioral parity for every numerical path.

PyPI installation and a first Unitree G1 simulation

For a user who only needs the published package, the shortest documented installation is installation from PyPI. This path is appropriate when repository development is unnecessary and the local environment already meets the package's Python and dependency requirements.

pip install mujoco-warp

After installation, the README provides a concrete first use that launches a locally viewable humanoid simulation. This is more useful as an initial check than importing the library without a visible result, because it exercises scene loading, simulation, and the viewer path together.

python benchmarks/run.py -f unitree_g1_flat --view

The benchmark file is supplied by the cloned repository, so this particular command assumes that the `benchmarks/` directory is present in the working tree. For users who want the examples and development environment, the repository workflow is:

git clone https://github.com/google-deepmind/mujoco_warp.git && cd mujoco_warp

From that checkout, the Unitree G1 command can be run. The project also offers a browser tutorial with no local setup:

The browser tutorial is the more accessible starting point when NVIDIA setup, dependency installation, or local GPU configuration would otherwise delay evaluation. The README does not give local installation steps for that hosted tutorial, so no additional command should be inferred from it.

Developer setup, tests, and Warp kernel checks

Contributors should use the repository's `uv` workflow rather than treating the PyPI installation as the complete development setup. The project documents synchronization of all optional dependencies, installation of pre-commit checks, and execution of the test suite. The pre-commit configuration covers `ruff`, `uv-lock`, and `kernel-analyzer` checks, which is relevant because MJWarp contains performance-sensitive Warp kernels.

uv sync --all-extras
uv run pre-commit install
uv run pytest -n 8

The repository includes a kernel analyzer under `contrib/kernel_analyzer`. The README says to use its VS Code plugin when writing Warp kernels and states that the same analyzer runs on pull requests. Contributors should therefore account for kernel analysis before treating a local commit as ready for review.

For profiling, the repository exposes `mjwarp-testspeed` with an `--event_trace` flag. The documented invocation uses the humanoid scene:

mjwarp-testspeed benchmarks/humanoid/humanoid.xml --event_trace

The README describes this as producing a full trace on a chosen test scene and points to `mjwarp-testspeed --help` for configuration options. That command is useful for investigating GPU execution rather than judging correctness. The README does not publish a portable performance number in this page, so a prospective user should not assume a specific speedup without examining the project's nightly benchmark results for the relevant scene and hardware.

JAX, PyTorch, Isaac Lab, and mjlab integration paths

MJWarp's integration options differ according to the research stack. For JAX users, the README points to MJX as the route for accessing MJWarp, and it references MuJoCo Playground for robotics machine learning recipes. This is an ecosystem integration rather than a claim that MJWarp provides a separate JAX-specific API in this repository.

PyTorch researchers have two documented options. Isaac Lab integrates MJWarp through Newton, which places the simulator within an NVIDIA-oriented physics and robotics stack. The README characterizes that route as extensible and connected to the broader NVIDIA ecosystem, but it does not provide a complete Isaac Lab setup here. The mjlab alternative exposes Isaac Lab's manager-based API directly on top of MJWarp and is described as a focused framework with minimal dependencies and direct access to native MuJoCo data structures.

The choice is architectural. Isaac Lab through Newton is appropriate when a project benefits from the larger multi-physics framework. mjlab is the closer choice when direct MJWarp access, the manager-based API, and a narrower dependency set are the stated priorities. Neither option removes MJWarp's documented compatibility gaps, and neither should be treated as proof that all MuJoCo plugins, integrators, solvers, or Flex features work.

The README also lists command-line entry points for speed tests, viewing, and recording, including `mjwarp-testspeed`, `mjwarp-viewer`, and `mjwarp-record`. Their presence indicates useful operational tooling, but the README excerpt does not specify the arguments accepted by the latter two commands.

Release cadence, alpha status, and upgrade cost

The repository is not archived. Its last push was on 2026-10-14, and recent releases include `v3.16.0` on 2026-10-14, `v3.15.0` on 2026-10-05, and `v3.14.0` on 2026-09-22. This is a recent change record, but it does not by itself guarantee compatibility for every existing MuJoCo workload.

The package metadata classifies version 3.16.0 as `Development Status :: 3 - Alpha`. That label is more informative for adoption planning than the release number alone. MJWarp is closely connected to MuJoCo and NVIDIA Warp, so an upgrade can affect dependency resolution, CUDA or Warp behavior, kernels, and model execution. The declared dependencies include `mujoco>=3.13.0`, `warp-lang>=1.15`, `numpy`, `absl-py`, and `etils[epath]`.

Upgrading from MuJoCo to MJWarp can also require model and test changes. Integrator and solver availability differ, plugin actuators and sensors are absent, Flex is incomplete, and Warp differentiability is not available. Nightly benchmarks are published by the project, which gives evaluators a source for workload-specific results, but the README does not promise identical results across every hardware configuration or API path.

The project carries the `Apache-2.0` license according to `pyproject.toml`. That identifier describes the project's licensing choice, but this review does not provide legal interpretation or advice about how it applies to a particular deployment.

Editorial conclusion

Adopt MuJoCo Warp when robotics workloads need many MuJoCo simulations on NVIDIA hardware and the documented compatibility gaps do not affect the model. Do not adopt it as an exact MuJoCo substitute when `IMPLICITFAST`, `PGS`, `noslip` with the `discrete` integrator, plugin actuators or sensors, complete Flex behavior, or Warp differentiability are required. Verify GPU support, MuJoCo model compatibility, package versions, and the application integrator and solver before migration.

Frequently asked questions

Official sources

1. google-deepmind/mujoco_warp on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases