Research: Containerizing games with docker

[voidderef]

In GitLab by @icex2 on Apr 24, 2020, 23:28

Summary

Run piu games in docker containers to provide an additional level of abstracting making them more independent of the base system.

Detailed description

I have already done some testing with this but didn't get really far. I installed nvidia-docker and started with an ubuntu 16.04 nvidia opengl docker container as a base: https://hub.docker.com/r/nvidia/opengl
glxgears was running just fine. Mounting the game data of piu zero as a volume to the container, I tried running it but the game fails when opening the display on XOpenDisplay. I played around a bit but the call was always returning NULL even when setting the display explicitly to :0 which was also "bound" to the container using --env="DISPLAY=:0" ($DISPLAY also yielded :0 and my host display was named like that).

Whoever is reading this, feel free to pick this up if you are interested. If you do, I would appreciate if you leave a note in the comments. If you have any new findings or even a proof of concept, I am looking forward to your contribution.

Some references I used in descending order of relevance:

http://wiki.ros.org/docker/Tutorials/Hardware%20Acceleration

https://www.pugetsystems.com/labs/hpc/Docker-and-NVIDIA-docker-on-your-workstation-Using-Graphical-Applications-915/

https://misha.brukman.net/blog/2020/04/running-decade-old-games-in-containers/

Benefits

Naturally, this makes the games more base OS independent benefitting overall compatibility over time. The games can keep on running on "outdated" and isolated containers and pumptools doesn't have to catch up with any/less changes required to make the games run on newer kernels and distros with updated depedencies.

Drawbacks

Maybe performance might be something to consider here regarding latency but that needs to be tested.

Current blockers

None.

[voidderef]

In GitLab by @icex2 on Apr 25, 2020, 12:21

changed the description

[voidderef]

In GitLab by @Littletiger on May 2, 2020, 14:26

I'm going to give this a try and see how far I can get with it :)

[voidderef]

In GitLab by @icex2 on May 2, 2020, 19:10

Cool, please keep me in the loop about any progress. Feel free to use this issue for notes and stuff.

[voidderef]

In GitLab by @Littletiger on May 3, 2020, 17:11

I've spent quite a few hours on this over the last 2 days, here are my thoughts/findings:

I've gotten opengl support to work on a AMD and Nvidia card.

It will run applications like glxgears and stepmania5 fine but not pump.

When trying to do: piueb run in a container it will always come back with:

[I][2020/5/3-14:54:20:601][patch-gfx][gfx.c:80] XOpenDisplay: (null)
[E][2020/5/3-14:54:20:602][patch-gfx][gfx.c:87] XOpenDisplay returned NULL. This might indicate that your environment is not properly setup. Check that you have GPU drivers installed and configured properly and that OpenGL hardware acceleration is working (use the command line tool "glxinfo").

I think there's an issue with the way the hook.so does the GPU patch and trys to grab a X screen.

If I comment out the local LD_PRELOAD="$HOOK_FILE" it will show the game window with an error about the missing dongle.

However if I copy in the cabinet-run and xorg scripts from pumpos and run via X it works!(Without input yet)

[voidderef]

In GitLab by @Littletiger on May 3, 2020, 17:20

I've done a little bit of performance testing using glmark2

Nvidia GT 1030:

Native: glmark2 Score: 4619
Docker: glmark2 Score: 4570

AMD R7 250:

Native: glmark2 Score: 1916
Docker: glmark2 Score: 1334

Nvidia performance is pretty close but AMD is awful

[voidderef]

In GitLab by @icex2 on May 4, 2020, 24:30

Nevertheless, the pump games might be just fine even with a ~1/3rd drop in performance. Thanks for these values. I think that gives us at least a rough idea that this might be promising and fine for pump games.

[voidderef]

In GitLab by @icex2 on May 4, 2020, 24:35

Thanks for the elaborate testing. As I haven't tried anything besides glxgears and one of the pump games, that's great to hear that stepmania 5 runs fine. I assume by "fine" you also mean that it runs fine performance wise regarding framerate, timing and (input) latency?

Regarding pump, I ran into the exact same issue you describe with XOpenDisplay: (null).

However if I copy in the cabinet-run and xorg scripts from pumpos and run via X it works!(Without input yet)

Nice. When you just run piueb run the game lacks any proper X environment setup. Therefore, there is no display available. However, I have tried some manual tests with xinit + piueb but might have used non suitable parameters. The game was still complaining about not getting a display.

So, you got the game running with the hook or without it?

[voidderef]

In GitLab by @Littletiger on May 4, 2020, 18:19

With the hook, using the run.sh, cabinet-startx.sh, cabinet-start.sh and xorg.conf

Shouldn't need to essentially run 2 X servers though.

[voidderef]

In GitLab by @icex2 on May 4, 2020, 20:08

Maybe a useful reference to support strace once the fundamental features are working: https://jvns.ca/blog/2020/04/29/why-strace-doesnt-work-in-docker/

[voidderef]

In GitLab by @icex2 on May 4, 2020, 20:14

If you run it that way, you should not get multiple X servers.

Then, that's great news. Do you mind opening a WIP MR with your current progress? Once you have a working proof of concept, we can take it from there and have a look at what else we need to support. Here is a mind-dump of what we need for the games, ascending order regarding their priority (imo):

• Sound
• USB device/controller (e.g. PIUIO) support -> device pass through?
• Latency check game IO hardware
• USB stick support -> NX2 and newer
• Docker image with environment, only. Assets and pumptools provided via mountable volume. Feel free to challenge me on this. But, I think building everything into the container has quite the drawbacks regarding updatability and building the container itself.
• Support debug, strace etc features of piueb -> different run modes

[voidderef]

In GitLab by @Littletiger on May 4, 2020, 22:18

I did test Stepmaina on my pumpos based GX

Sound and USB passthrough was working :D

I didn't notice any delay with the pads(But I suck so maybe there was)

The container with pump however I haven't got the input working yet, maybe its something to with the way its running X. I will need to investigate more.

Docker image with environment, only.

This is how I've been doing it so it can run any game and easily switch, I prefer to make containers as small as possible.

I will do some more testing, remove unnecessary packages then make a MR

[voidderef]

In GitLab by @icex2 on May 16, 2020, 15:05

Bump, any update on this? @Littletiger
If you have a lack of time right now, you can also just open a wip MR with whatever you have so far. I might want to look into finalizing this.

[voidderef]

In GitLab by @Littletiger on May 17, 2020, 11:46

Sorry, I didn't get chance to do anything this week.

Everything is working accept keyboard input, which might be auto discovery in the x11 config doesn't work in a container, I've tried a few different config files but it's not working, I'll open a MR with what I have.

[voidderef]

In GitLab by @icex2 on May 17, 2020, 12:48

No worries. Not wanting to take this away from you, if you still want to continue on that task. However, I might be in the need of that earlier than expected. Therefore, it would be great to continue where you left off instead of having to build it from scratch. I will keep you in the loop about any developments regarding this topic.

[voidderef]

In GitLab by @icex2 on Jul 13, 2020, 21:59

Notes and references:
Maybe a suitable alternative for what docker tries to achieve for the pump games avoiding docker as a hard dependency:
http://statifier.sourceforge.net/
http://www.magicermine.com/products.html

The above tools pack dynamic libraries and executables into a single executable. I assume this gets rid of any versioning issues with differetn glibc builds and other dependencies as it's supposed to act like LD_LIBRARY_PATH.

However, this needs to be evaluated.