Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rendering is broken when vram is contested #573

Open
mishmish66 opened this issue Nov 21, 2024 · 4 comments
Open

Rendering is broken when vram is contested #573

mishmish66 opened this issue Nov 21, 2024 · 4 comments

Comments

@mishmish66
Copy link
Contributor

mishmish66 commented Nov 21, 2024

System Info

I am using Ubuntu 24.04. I've reproduced this issue on python 3.10, 3.11, and 3.12 and with the current state of the repo as well as the latest version on pypy, and the version from a few commits ago on the main branch.

Information

This problem arises when VRAM is contested and offscreen rendering is used.
I introduced this issue with PR #570

I'll introduce a fix for this momentarily. So sorry to introduce this but hopefully I can get this fix in fast.

Reproduction

Run a large model and robosuite offscreen rendering at the same time

Expected behavior

I would expect robosuite rendering to be agnostic to the amount of VRAM available and in use

@mishmish66 mishmish66 changed the title New PR I made breaks rendering when vram is contested Rendering is broken when vram is contested Nov 21, 2024
@mishmish66
Copy link
Contributor Author

While this is still an issue I've realized this isn't due to the PR I made (whew) here is a video of what happens.

I'll work on figuring out what's going on here.

@kevin-thankyou-lin
Copy link
Contributor

kevin-thankyou-lin commented Nov 22, 2024

Hey @mishmish66, thanks for the PR! Are you able to reproduce this issue on older robosuite versions too?

@mishmish66
Copy link
Contributor Author

mishmish66 commented Nov 22, 2024

Hey! I confirmed this happens with v1.5.0, but it seems to only happen once the EGL context is reloaded, which I guess people might not do too often?

In case anyone encounters this issue and finds this thread before this has been fixed, a workaround which is to set
renderer="mujoco"
instead of the default which was "mjviewer" in the case I was working with

@abhihjoshi
Copy link
Contributor

Not sure if this would work, but another thing you could try is to set MUJOCO_GL=egl as an env variable prior to running your code (i.e., MUJOCO_GL=egl python foo_bar.py).

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

No branches or pull requests

3 participants