chenlin/Mujoco_WASM
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update M1 Pro with M3 Max benchmarks in MJX docs

Browse Source 
PiperOrigin-RevId: 584918133
Change-Id: I442972cdc1f19020e6b5bbc7ff3e98fd556cf125
This commit is contained in:
Yuval Tassa
2023-11-23 10:45:57 -08:00
committed by Copybara-Service
parent f2025c6abf
commit 6a83b86553
4 changed files with 8 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/XMLreference.rst
+4 -4
View File
@@ -5787,10 +5787,10 @@ Associate this actuator with an :ref:`engine plugin<exPlugin>`. Either :at:`plug
.. _actuator-plugin-dyntype: .. _actuator-plugin-dyntype:
:at:`dyntype`: :at-val:`[none, integrator, filter, filterexact, muscle, user], "none"` :at:`dyntype`: :at-val:`[none, integrator, filter, filterexact, muscle, user], "none"`
Activation dynamics type for the actuator. The available dynamics types were already described in the Activation dynamics type for the actuator. The available dynamics types were already described in the :ref:`Actuation
:ref:`Actuation model <geActuation>` section. See also :ref:`actuator-general-dyntype`. If dyntype is model <geActuation>` section. If :ref:`dyntype<actuator-general-dyntype>` is not "none", an activation variable will
not none, an activation variable will be added to the actuator. This variable will be added after be added to the actuator. This variable will be added after any activation state computed by the plugin (see
any activation state computed by the plugin (see :ref:`actuator plugin activations<exActuatorAct>`). :ref:`actuator plugin activations<exActuatorAct>`).
.. _actuator-plugin-actrange: .. _actuator-plugin-actrange:
doc/images/mjx/SPS.svg
+1 -1
View File
File diff suppressed because one or more lines are too long
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 93 KiB

After

Width:  |  Height:  |  Size: 94 KiB

doc/mjx.rst
+2 -2
View File
@@ -296,7 +296,7 @@ Large, complex scenes with many contacts
powerful as the one in MuJoCo. powerful as the one in MuJoCo.
To see how this affects simulation, let us consider a physics scene with increasing numbers of humanoid bodies, To see how this affects simulation, let us consider a physics scene with increasing numbers of humanoid bodies,
varied from 1 to 10. We simulate this scene using CPU MuJoCo on an Apple M1 Pro and a 64-core AMD 3995WX and time varied from 1 to 10. We simulate this scene using CPU MuJoCo on an Apple M3 Max and a 64-core AMD 3995WX and time
it using :ref:`testspeed<saTestspeed>`, using ``2 x numcore`` threads. We time the MJX simulation on an Nvidia it using :ref:`testspeed<saTestspeed>`, using ``2 x numcore`` threads. We time the MJX simulation on an Nvidia
A100 GPU using a batch size of 8192 and an 8-chip A100 GPU using a batch size of 8192 and an 8-chip
`v5 TPU <https://cloud.google.com/blog/products/compute/announcing-cloud-tpu-v5e-and-a3-gpus-in-ga>`__ `v5 TPU <https://cloud.google.com/blog/products/compute/announcing-cloud-tpu-v5e-and-a3-gpus-in-ga>`__
@@ -306,7 +306,7 @@ Large, complex scenes with many contacts
:width: 95% :width: 95%
:align: center :align: center
The values for a single humanoid (leftmost datapoints) for the four timed architectures are **320K**, **1.8M**, The values for a single humanoid (leftmost datapoints) for the four timed architectures are **650K**, **1.8M**,
**950K** and **2.7M** steps per second, respectively. Note that as we increase the number of humanoids (which **950K** and **2.7M** steps per second, respectively. Note that as we increase the number of humanoids (which
increases the number of potential contacts in a scene), MJX throughput decreases more rapidly than MuJoCo. increases the number of potential contacts in a scene), MJX throughput decreases more rapidly than MuJoCo.
doc/programming/extension.rst
+1 -1
View File
@@ -206,7 +206,7 @@ Actuator activations
When writing stateful actuator plugins, there are two choices for where to save the actuator state. One option is using When writing stateful actuator plugins, there are two choices for where to save the actuator state. One option is using
``plugin_state`` as described above, and the other is to use ``mjData.act`` by implementing the ``actuator_actdim`` and ``plugin_state`` as described above, and the other is to use ``mjData.act`` by implementing the ``actuator_actdim`` and
``actuator_act_dot`` callbacks on :ref:`mjpPlugin`. ``actuator_act_dot`` callbacks on :ref:`mjpPlugin`.
When using the latter option, the actuator plugin's state will be added to ``mjData.act``, and MuJoCo will When using the latter option, the actuator plugin's state will be added to ``mjData.act``, and MuJoCo will
automatically integrate ``mjData.act_dot`` values between timesteps. One advantage of this approach is that automatically integrate ``mjData.act_dot`` values between timesteps. One advantage of this approach is that