Skip to content

Conversation

@oursland
Copy link

Brings in MPS support changes from @araffin along with the SinglePrecision env from naumix's BiggerRegularizedOptimistic (BRO).

Description

Apple silicon devices may be accelerated through the Metal Performance Shaders (mps) backend of PyTorch. This PR brings in the appropriate changes to support this backend.

Envs can be wrapped with the SinglePrecision env to ensure that the accelerator is only presented with float32s, which is a strict requirement for MPS.

Motivation and Context

Addresses #914

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation (update in the documentation)

Checklist

  • I've read the CONTRIBUTION guide (required)
  • I have updated the changelog accordingly (required).
  • My change requires a change to the documentation.
  • I have updated the tests accordingly (required for a bug fix or a new feature).
  • I have updated the documentation accordingly.
  • I have opened an associated PR on the SB3-Contrib repository (if necessary)
  • I have opened an associated PR on the RL-Zoo3 repository (if necessary)
  • I have reformatted the code using make format (required)
  • I have checked the codestyle using make check-codestyle and make lint (required)
  • I have ensured make pytest and make type both pass. (required)
  • I have checked that the documentation builds using make doc (required)

Note: You can run most of the checks using make commit-checks.

Note: we are using a maximum length of 127 characters per line

@oursland
Copy link
Author

Without wrapping the Gymnasium envs with the SinglePrecision env wrapper, many (all?) will not run with the mps backend.

It looks like the upstream Gymnasium envs frequently specify float64 as the data type (i.e. here). I suspect this is due to MuJoCo defaulting to double types in the engine, although it can be built with float as the number data type. I believe the added precision may be valuable in intermediate computation, but less likely as the output data type of the simulator.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants