[containers] Enables container support for scenes that use visual obsvervations #547

eshvk · 2018-03-27T23:17:31Z

Based on @AdamPalmarUnity's setup. Please take your time to test and try it out.

mmattar

Just feedback on diffs ... will try running it tomorrow.

mmattar · 2018-03-28T00:26:38Z

python/unityagents/environment.py

+                     '--port', str(self.port),
+                     '--seed', str(seed)])
+            else:
+                docker_ls = ("exec xvfb-run --auto-servernum"


A comment explaining docker_ls would be very helpful here, particularly with regards to the dimensions (640x480x24).

mmattar · 2018-03-28T00:30:04Z

docs/Using-Docker.md

 # Using Docker For ML-Agents (Experimental)

-We currently offer an experimental solution for Windows and Mac users who would like to do training or inference using Docker. This option may be appealing to those who would like to avoid installing Python and TensorFlow themselves. The current setup forces both TensorFlow and Unity to _only_ rely on the CPU for computations. Consequently, our Docker support is limited to environments whose agents **do not** use camera-based visual observations. For example, the [GridWorld](Learning-Environment-Examples.md#gridworld) environment is **not** supported.
+We currently offer a solution for Windows and Mac users who would like to do training or inference using Docker. This option may be appealing to those who would like to avoid installing Python and TensorFlow themselves. The current setup forces both TensorFlow and Unity to _only_ rely on the CPU for computations. Consequently, our Docker simulation [uses the CPU](https://en.wikipedia.org/wiki/Xvfb) to do visual rendering. This means that environments which involve agents using camera-based visual observations might be slower.


Linking to https://en.wikipedia.org/wiki/Xvfb in "uses the CPU" was a bit counter-intuitive for me.

The very end of this sentence "might be slower", presumably you mean training and inference speeds. I would clarify that. (Optional: is there anything we can say regarding how much slower we expect it to run?)

Linking to https://en.wikipedia.org/wiki/Xvfb in "uses the CPU" was a bit counter-intuitive for me.
Xvfb is a virtualized XServer which does not use the GPU, would you prefer if the text hyperlinked said does not use the GPU ?

The very end of this sentence "might be slower", presumably you mean training and inference speeds. I would clarify that. (Optional: is there anything we can say regarding how much slower we expect it to run?)

I mean training. Although you could very well use the container for inference as well, it seems more designed for a training use case. I will clarify there.

We are not significantly slower for the environments we support currently. Having said that, we are using the CPU to do computation which is typically done in a GPU. So when we do get to more complex and rich rendering scenes, I expect performance to drop. That phrase was mostly added to ward off potential issues popping up on Github in the mean time.

I think if we're going to link to Xvfb then we should probably introduce it here too.

mmattar · 2018-03-28T00:32:12Z

docs/Using-Docker.md

@@ -1,6 +1,7 @@
 # Using Docker For ML-Agents (Experimental)


Remove "(Experimental)"? If so, then also remove it from the Repo Homepage (features section).

(Minor) In this page we used 3D Ball as the running example for container and env names. But now the image "docker_build_settings.png" links to the Gridworld scene. I think we ought to either update the naming conventions or have the image point to 3Dball, just for consistency.

Both good points. Will fix.

awjuliani · 2018-03-28T16:50:07Z

Would it be possible to provide a lightweight container for only doing vector observations, and this new one for visual observations? I think if it isn't necessary, we should direct people to use headless mode and the slimmer image.

eshvk · 2018-03-28T17:10:29Z

@awjuliani I am not sure I understand what slimmer or lightweight mean in this context. If you mean that there are more lines in the DockerFile, it is because we are taking content from the previous base image. The only changes from the previous container is that we are using Ubuntu and installing xvfb.

As far as headless is concerned, someone who wants to use only vector observations can very well build a headless Unity build and use it with our current setup. I am happy to add a note on that.

Lakrix · 2018-03-29T06:16:38Z

When trying out docker image from develop-feature-docker-improvements I get the following error.

Debug info from gdb:

mono_gdb_render_native_backtraces not supported on this platform, unable to find gdb or lldb

Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.

Traceback (most recent call last):
File "python/learn.py", line 62, in
tc.start_learning()
File "/execute/python/unitytrainers/trainer_controller.py", line 230, in start_learning
curr_info = self.env.reset(train_mode=self.fast_simulation)
File "/execute/python/unityagents/environment.py", line 276, in reset
return self._get_state()
File "/execute/python/unityagents/environment.py", line 287, in _get_state
state_dict, end_of_message = self._get_state_dict()
File "/execute/python/unityagents/environment.py", line 243, in _get_state_dict
state = self._recv_bytes().decode('utf-8')
File "/execute/python/unityagents/environment.py", line 219, in _recv_bytes
message_length = struct.unpack("I", bytearray(s[:4]))[0]
struct.error: unpack requires a buffer of 4 bytes

I run it on a Mac.

eshvk · 2018-03-29T08:58:53Z

Hi @Lakrix,
Can you please create a separate issue to track this? This PR is a work in progress being internally tested:

Some useful information would be:

Have you been able to get the environment working without using docker on the mac?
Are you using an x86_64 linux image?
Did you see any docker build errors when your image is being created?

mmattar

One additional comment on the older version of this file .... in the "docker run --name 3DBallContainer.first.trial \ ..." command - the environment name should be changed from "3Dball" to "3DBall".

mmattar · 2018-04-02T17:29:22Z

docs/Using-Docker.md


+**NOTE** If you are only collecting vector observations from Unity, you can select the `headless` option here:
+
+![Build Settings For Docker](images/docker_build_settings_headless.png)


I don't see a difference between the *_headless.png and *_noheadless.png images, except that headless points to the GridWorld scene, while noheadless points to the 3DBall scene.

That was a typo. I think I didn't commit the updated file. The _headless.png should be identical to the _noheadless.png except for the former having headless checked.

mmattar · 2018-04-02T17:31:16Z

docs/Using-Docker.md


 Then click `Build`, pick an environment name (e.g. `3DBall`) and set the output directory to `unity-volume`. After building, ensure that the file `<environment-name>.x86_64` and subdirectory `<environment-name>_Data/` are created under `unity-volume`.

+**NOTE** If you are only collecting vector observations from Unity, you can select the `headless` option here:


Consider including the headless commentary in the list above. That why when a user is following the instructions, they better understand what role the headless option represents.

"If you are only collecting vector observations from Unity" --> "If the environment does not contains visual observations"

Reason for this change too is that headless presumably is about visual, so if they're using vector and/or text observations then they should be ok.

So I am going to fold the NOTE into the checklist. Let me know if you think the two images for the headless and noheadless options seem useless now?

vincentpierre

Modify docs/Readme.md
Merge docs/images/docker_build_settings_headless.png and docs/images/docker_build_settings_noheadless.png into one image with annotation.

vincentpierre · 2018-04-03T23:15:00Z

It works for me feel free, the changes I requested are only around docs

eshvk · 2018-04-04T20:36:44Z

@vincentpierre check new annotated image please.

…ervations

eshvk requested review from AdamPalmarUnity, awjuliani, mmattar, vincentpierre and xiaomaogy March 27, 2018 23:17

mmattar reviewed Mar 28, 2018

View reviewed changes

awjuliani mentioned this pull request Mar 28, 2018

How to run more than one unity instance on the linux server #305

Closed

eshvk force-pushed the develop-feature-docker-improvements branch from 45071b7 to c8130ba Compare March 30, 2018 17:44

mmattar reviewed Apr 2, 2018

View reviewed changes

mmattar approved these changes Apr 2, 2018

View reviewed changes

vincentpierre suggested changes Apr 3, 2018

View reviewed changes

[containers] Enables container support for scenes that use visual obs…

0afcc73

…ervations

eshvk force-pushed the develop-feature-docker-improvements branch from 0c6bf42 to 0afcc73 Compare April 4, 2018 21:34

eshvk merged commit ee366ff into develop Apr 4, 2018

eshvk deleted the develop-feature-docker-improvements branch April 4, 2018 22:47

github-actions bot locked as resolved and limited conversation to collaborators May 20, 2021


		NOTE If you are only collecting vector observations from Unity, you can select the `headless` option here:

		![Build Settings For Docker](images/docker_build_settings_headless.png)


		Then click `Build`, pick an environment name (e.g. `3DBall`) and set the output directory to `unity-volume`. After building, ensure that the file `<environment-name>.x86_64` and subdirectory `<environment-name>_Data/` are created under `unity-volume`.

		NOTE If you are only collecting vector observations from Unity, you can select the `headless` option here:

[containers] Enables container support for scenes that use visual obsvervations #547

[containers] Enables container support for scenes that use visual obsvervations #547

Uh oh!

Conversation

eshvk commented Mar 27, 2018

Uh oh!

mmattar left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

awjuliani commented Mar 28, 2018

Uh oh!

eshvk commented Mar 28, 2018

Uh oh!

Lakrix commented Mar 29, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

eshvk commented Mar 29, 2018

Uh oh!

mmattar left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vincentpierre left a comment

Choose a reason for hiding this comment

Uh oh!

vincentpierre commented Apr 3, 2018

Uh oh!

eshvk commented Apr 4, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Lakrix commented Mar 29, 2018 •

edited

Loading