-
Notifications
You must be signed in to change notification settings - Fork 37
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
Added RunTime set of images that are slimmer and a jupyter bonus #68
base: main
Are you sure you want to change the base?
Added RunTime set of images that are slimmer and a jupyter bonus #68
Conversation
Signed-off-by: Aloys Baillet <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems super useful, and USD in a Jupyter notebook is definitely very cool.
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
136fdf2
to
ed1b190
Compare
I've been experimenting with adding a real Xorg instance inside the docker container, with an extra I've been trying to research ways of starting Xorg without TTY but so far no luck... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, the xpra stuff is intriguing, I had not heard about it before. Running Xorg inside of a container seems like one of those "why would you want to do that?" requirements since in most scenarios you have control over how you start the container, and are able to run X11 outside the container(s). I wonder if there's a way to get xpra to forward pixels being rendered to a surface allocated via EGL without having X11 involved?
I'm going to try what Qt can do with EGL and without X11... having Qt to abstract things around might be quite useful with PySide and Jupyter (see the usdrecord snippet that needs a Qt app and a QGLWidget). |
Signed-off-by: Thomas Mansencal <[email protected]>
Signed-off-by: Simran Brucherseifer <[email protected]>
Signed-off-by: Simran Spiller <[email protected]>
Signed-off-by: Simran Brucherseifer <[email protected]>
Signed-off-by: Simran Spiller <[email protected]>
Signed-off-by: Simran Spiller <[email protected]>
Signed-off-by: Simran Spiller <[email protected]>
Signed-off-by: Simran Spiller <[email protected]>
Signed-off-by: Simran Spiller <[email protected]>
Signed-off-by: Simran Spiller <[email protected]>
Signed-off-by: Simran Spiller <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
If you try to use shell scripts to install packages directly, e.g. in a location other than /usr/local, a couple of them cause problems. In build_pyside.sh, don't try to create /tmp/qt5temp/bin/qt.conf if the user has not in fact moved Qt to /tmp/qt5temp. In build_usd.sh, specify GLEW_LOCATION explicitly. Signed-off-by: Geoff Levner <[email protected]>
Signed-off-by: Geoff Levner <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
Signed-off-by: Aloys Baillet <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This review might get invalidated when you update this branch, but this still looks like really useful functionality. Does it need some notes in README.md to explain the purpose of CI vs RT images?
Thanks JF, indeed I'll make sure I add more info in the readme once the images are ready! |
This is a "working draft" of a new set of ASWF docker images for "run-time" instead of CI. They are slimmer and only contain the build artifacts without any compiler.
rt-vfxall
is around 1.8GB whenci-vfxall
is 2.6GB.I've added a
rt-vfxall-jupyter
that contains a Jupyter notebook that is able to access full USD and GPUs, as shown in this screenshot:(To run:
docker run -it --rm --gpus=all -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix:rw -v ~/Downloads/Kitchen_set:/home/jovyan/work -p 8888:8888 aswftesting/rt-vfxall-jupyter:2020
)I feel that these images should be quite generally useful as well, and probably easier to understand than the CI ones.
Any thoughts?