Support Windows + GPU

[phil294]

Is this possible? If not, it would be good to have https://github.com/mviereck/x11docker/wiki/x11docker-on-MS-Windows state it.
Greetings

Edit: Thanks! Ill be testing this in a few days, please dont close
edit2: I dont use a Windows machine myself. Hopefully next few days I can continue testing on a friends computer.

[mviereck]

--gpu on Windows should work and I got one confirmation. Though, I cannot test it myself because I don't have a native Windows installation.

Technically it works different than on Linux. On Linux the GPU device files are shared with the container, and container applications access it directly (direct rendering).

On Windows direct rendering is not possible, but X servers VcXsrv and Xwin provide GPU support with indirect rendering (GPU requests forwarded through the X server).
From their documentation it should work in seamless mode (single windows) but not in desktop mode (All windows collected in a parent window).

Could you please show me the output of:

 x11docker --gpu -- x11docker/xfce glxinfo | grep -E 'OpenGL|render'

That should contain some infos of your GPU hardware visible by the container.

---

For comparison: Output on Linux with AMD GPU:

direct rendering: Yes
    GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
    GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, 
Extended renderer info (GLX_MESA_query_renderer):
OpenGL vendor string: X.Org
OpenGL renderer string: AMD MULLINS (DRM 2.50.0, 4.19.0-4-amd64, LLVM 7.0.1)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.3.4
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
    GL_ARB_compute_variable_group_size, GL_ARB_conditional_render_inverted, 
    GL_NVX_gpu_memory_info, GL_NV_conditional_render, GL_NV_depth_clamp, 
OpenGL version string: 4.5 (Compatibility Profile) Mesa 18.3.4
OpenGL shading language version string: 4.50
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL extensions:
    GL_ARB_compute_variable_group_size, GL_ARB_conditional_render_inverted, 
    GL_NV_conditional_render, GL_NV_depth_clamp, GL_NV_fog_distance, 
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 18.3.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:
    GL_OES_element_index_uint, GL_OES_fbo_render_mipmap, 

Most of interest are the lines:

direct rendering: Yes
OpenGL renderer string: AMD MULLINS (DRM 2.50.0, 4.19.0-4-amd64, LLVM 7.0.1)

[mviereck]

Closing due to inactivity.

@phil294 feel free to reopen. I'd be happy to hear if it works for you.

[mviereck]

Reopening due to issues reported in #145.

[eine]

As commented in #145, x11docker --gpu -- x11docker/xfce glxinfo does not work on my workstation; glxgears produces a crash. I am using VcXsrv 1.20.1.4 and the GPU is a NVIDIA GeForce GTX 1060 with driver version 381.65.

EDIT

I updated the driver to 430.64, with the same result.

[mviereck]

@1138-4eb
What does x11docker --gpu x11docker/check glxinfo show on your workstation? Just nothing?
Does x11docker --gpu x11docker/check glxgears show any output?
Does x11docker --gpu x11docker/check glxspheres64 show any output?

Could you show the results from the laptop that works for comparision? The laptop has an NVIDIA card, too?

Does one or both machines have an integrated non-NVIDIA GPU?

Edit:
It could be of interest to compare with --xwin in Cygwin/X if it has the same issue. I assume yes.
Furthermore, I assume the issue is specific to NVIDIA cards.
I assume that VcXsrv on the laptop that does not fail uses an integrated non-NVIDIA GPU.

[eine]

What does x11docker --gpu x11docker/check glxinfo show on your workstation? Just nothing?

I opened 'Run a bash terminal' and executed glxinfo inside. It shows: name of display: 10.0.75.1:101 and it then crashes.

Does x11docker --gpu x11docker/check glxgears show any output?

No. A black window is shown, where the gears should be rendered; but no gear is seen. It crashes before drawing anything.

On the laptop, the gears are shown in the black square, and they seem to "move" for a couple of frames before freezing and crashing.

Does x11docker --gpu x11docker/check glxspheres64 show any output?

Polygons in scene: 62464 (64 spheres * 1024 polys/spheres) is shown and it then crashes. Sometimes some more info is shown:

Polygons in scene: 62464 (64 spheres * 1024 polys/spheres)
Visual ID of window: 0x2c1
Cont

Could you show the results from the laptop that works for comparision? The laptop has an NVIDIA card, too?

The laptop has and Intel and an NVIDIA card. But I believe that the Intel one is being used (see #70).

Does one or both machines have an integrated non-NVIDIA GPU?

The laptop is an ASUS F555LD-XX110H with an NVIDIA GeForce GT 820M and an Intel Core i7-4510U (Intel HD Graphics 4400). The workstation has an i5-6600K (Intel HD Graphics 530), but the NVIDIA GTX 1060 is used.

[eine]

Could you show the results from the laptop that works for comparision?

glxinfo:

OpenGL vendor string: Intel
OpenGL renderer string: Intel(R) HD Graphics 4400
OpenGL version string: 1.4 (4.3.0 - Build 20.19.15.4549)
OpenGL extensions:

glxspheres:

Polygons in scene: 62464 (61 spheres * 1024 polys/spheres)
Visual ID of window: 0x73
Context is Indirect
OpenGL Renderer: Intel(R) HD Graphics 4400
208.877160 frames/sec - 193.996751 Mpixels/sec
0.266775 frames/sec - 0.247770 Mpixels/sec
268.848783 frames/sec - 249.695995 Mpixels/sec
140.452265 frames/sec - 130.446445 Mpixels/sec
115.540000 frames/sec - 107.308930 Mpixels/sec
121.222456 frames/sec - 112.586568 Mpixels/sec
119.343176 frames/sec - 110.841169 Mpixels/sec
127.253124 frames/sec - 118.187611 Mpixels/sec
128.773385 frames/sec - 119.599569 Mpixels/sec
130.664914 frames/sec - 121.356346 Mpixels/sec
126.964645 frames/sec - 117.919684 Mpixels/sec
126.347520 frames/sec - 117.346522 Mpixels/sec

glxgears:

Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
6006 frames in 5.5 seconds = 1100.395 FPS
3129 frames in 5.1 seconds = 613.255FPS

and it freezes/crashes.

[eine]

I think that it is not possible to select the integrated card on the workstation, because I'd need to physically connect the monitors to a different output. However, on the laptop the NVIDIA Control Panel allows me to bind the NVIDIA GPU to VcXsrv, instead of the Intel GPU which is the default. I am going to try that now.

[mviereck]

Do I understand correctly, that only glxgears crashes on the laptop that uses intel graphics?
glxspheres64 seems to run fine from its output and seems to really use the GPU. Does the animated graphic look well?

It seems x11docker should show a general warning on Windows for option --gpu that applications may work, but also can crash..

--gpu on Windows uses indirect rendering, a quite uncommon setup compared to Linux. Afaik X.org dropped indirect rendering a few years ago and only supports it for backwards compatibility.
x11docker sets environment variable LIBGL_ALWAYS_INDIRECT=1 on Windows with --gpu (https://github.com/mviereck/x11docker/blob/master/x11docker#L3014). I assume it must be set to use indirect rendering. It might be worth to run a test without this variable; but probably the GPU won't be used at all in that case.

Edit:

glxinfo:
OpenGL vendor string: Intel
OpenGL renderer string: Intel(R) HD Graphics 4400
OpenGL version string: 1.4 (4.3.0 - Build 20.19.15.4549)
OpenGL extensions:

Is this the full or a shortened output? On Linux glxinfo shows a big bunch of additional (low of interest) infos.

[eine]

When vcxsrv is bind to NVIDIA on the laptop, all the tests fail/crash. So, it seems that GPU acceleration with NVIDIA cards is not supported by vcxsrv.

EDIT: https://sourceforge.net/p/vcxsrv/bugs/94/

Do I understand correctly, that only glxgears crashes on the laptop that uses intel graphics?

Yes, that is it.

glxspheres64 seems to run fine from its output and seems to really use the GPU. Does the animated graphic look well?

Yes. It looks well, both with the Intel GPU on the laptop and with software rendering on the workstation.

It seems x11docker should show a general warning on Windows for option --gpu that applications may work, but also can crash..

This is sensible. However, isn't it surprising that glxgears fails but glxspheres works? Shouldn't glxgears be 'simpler'?

It might be worth to run a test without this variable; but probably the GPU won't be used at all in that case.

For which setup would this be interesting? For the Intel card or for NVIDIA?

Is this the full or a shortened output?

It's the full output if I click on 'Run glxinfo'. If I open a bash terminal and I execute glxinfo instead, I get much more info, as you say.

[mviereck]

Thanks for your answers, now I understand better. x11docker shows a warning now, and I've updated the wiki Windows page accordingly.

This is sensible. However, isn't it surprising that glxgears fails but glxspheres works? Shouldn't glxgears be 'simpler'?

Yes, it is surprising. However, glxgears is quite old. Maybe it was developed even before indirect rendering was introduced by X.org and somehow cannot handle that.

For which setup would this be interesting? For the Intel card or for NVIDIA?

I would first test with the Intel GPU to check if hardware acceleration works at all without this environment variable. However, according to the VcXsrv bug report I doubt that we can achieve anything.

---

What about the palinopsia leak check? Does it work with the intel GPU? Does it show some GPU memory content?

Could you also run a check in Cygwin/X with --xwin --gpu? I wonder if it has the same GPU issues as VcXsrv.

[eine]

What about the palinopsia leak check? Does it work with the intel GPU? Does it show some GPU memory content?

It fails with either Intel or NVIDIA. It works with the software rendering, I think.

Could you also run a check in Cygwin/X with --xwin --gpu? I wonder if it has the same GPU issues as VcXsrv.

glxinfo and glxspheres work ok. glxgears is loaded and the first frame is rendered, but it is not animated and no content is shown in the terminal. However, it does neither crash.

The palinopsia check works, although all black window is shown, so no video memory is leaked.

hardinfo works too, including the benchmarks.

EDIT

Would it be possible to support --xwin for MSYS2?

[mviereck]

[--xwin] glxinfo and glxspheres work ok. glxgears is loaded and the first frame is rendered, but it is not animated and no content is shown in the terminal. However, it does neither crash.
The palinopsia check works, although all black window is shown, so no video memory is leaked.

Did you check with Intel, NVIDIA or both of them? Does glxinfo show the GPU vendor in the renderer string?

Would it be possible to support --xwin for MSYS2?

In general it would be possible; I did not include it so far because it has the same features as --vcxsrv, but would need some more effort to provide it for MSYS2 and WSL.
However, if --gpu makes a big difference here, it might be worth the effort.

[phil294]

I got around to test a Windows machine (Nvidia GTX 1050 Ti) today, too:

x11 stuff works without --gpu just fine, which is awesome, including x11docker -- x11docker/xfce glxgears.
With --gpu, not:
x11docker --gpu -- x11docker/xfce glxinfo does not output anything, it just keeps running without any information, and so does x11docker --gpu -- x11docker/xfce glxgears (no window opens up).

I can try --xwin (Cygwin) tomorrow. I chose msys2 so far because it takes up the least amount of space. Have you thought about publishing x11docker as a docker image itself, running docker @mviereck ? As far as I can tell, the only thing that needs to be done outside of a container is the x11 setup: vcxsrv and display sharing docker options (could be wrapped inside a small batch file). Just a thought, not really necessary though.

[mviereck]

@phil294 Thank you for the feedback!

According to the VcXsrv bug ticket NVIDIA cards won't work with --vcxsrv.
A comparision check with --xwin in Cygwin/X would be quite helpful.

Instead of checks with x11docker/xfce I recommend the new image x11docker/check that provides some GPU check buttons.
Try: x11docker --gpu --clipboard x11docker/check

Have you thought about publishing x11docker as a docker image itself, running docker @mviereck ?

I did not think about this so far. I doubt it would make much sense because x11docker inside a container could not provide much more than the batch script that runs it.
The batch script could run the desired GUI container directly without adding x11docker in a container as an intermediate layer.

[eine]

[--xwin] glxinfo and glxspheres work ok. glxgears is loaded and the first frame is rendered, but it is not animated and no content is shown in the terminal. However, it does neither crash.
The palinopsia check works, although all black window is shown, so no video memory is leaked.

Did you check with Intel, NVIDIA or both of them? Does glxinfo show the GPU vendor in the renderer string?

I run the tests for NVIDIA (workstation). These are the results on the laptop:

x11docker --clipboard --xwin --gpu x11docker/check

Note that hardinfo works ok with both GPUs.

---

Showing GPU information with glxinfo. (x11docker option --gpu)

GPU seems to be accessible.
OpenGL renderer string: Intel(R) HD Graphics 4400

***************************************************

name of display: 10.0.75.1:100
display: 10.0.75.1:100  screen: 0
server glx vendor string: SGI
server glx version string: 1.4
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
GLX version: 1.4
OpenGL vendor string: Intel
OpenGL renderer string: Intel(R) HD Graphics 4400
OpenGL version string: 1.4 (4.3.0 - Build 20.19.15.4549)

Polygons in scene: 62464 (61 spheres * 1024 polys/spheres)
Visual ID of window: 0x73
Context is Indirect
OpenGL Renderer: Intel(R) HD Graphics 4400
272.757177 frames/sec - 253.325955 Mpixels/sec
135.687056 frames/sec - 126.020710 Mpixels/sec
144.832153 frames/sec - 134.514310 Mpixels/sec
137.169324 frames/sec - 127.397381 Mpixels/sec

Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
GL_RENDERER   = Intel(R) HD Graphics 4400
GL_VERSION    = 1.4 (4.3.0 - Build 20.19.15.4549)
GL_VENDOR     = Intel
VisualID 115, 0x73
22606 frames in 16.2 seconds = 1399.364 FPS
8337 frames in 14.2 seconds = 585.527 FPS
10806 frames in 11.9 seconds = 906.023 FPS
8342 frames in 11.8 seconds = 707.383 FPS
8337 frames in 11.9 seconds = 698.527 FPS
8347 frames in 12.0 seconds = 697.009 FPS

139
now initializing buffer nr. 0 of 139
now initializing buffer nr. 1 of 139
now initializing buffer nr. 2 of 139
now initializing buffer nr. 3 of 139
...
now initializing buffer nr. 138 of 139

---

Showing GPU information with glxinfo. (x11docker option --gpu)

GPU seems to be accessible.
OpenGL renderer string: GeForce 820M/PCIe/SSE2

***************************************************

name of display: 10.0.75.1:100
display: 10.0.75.1:100  screen: 0
server glx vendor string: SGI
server glx version string: 1.4
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
GLX version: 1.4
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce 820M/PCIe/SSE2
OpenGL version string: 1.4 (4.6.0 NVIDIA 390.65)

Polygons in scene: 62464 (61 spheres * 1024 polys/spheres)
Visual ID of window: 0x2f3
Context is Indirect
OpenGL Renderer: GeForce 820M/PCIe/SSE2
123.480857 frames/sec - 114.684081 Mpixels/sec
67.518146 frames/sec - 62.708154 Mpixels/sec
61.162670 frames/sec - 56.805441 Mpixels/sec
60.014904 frames/sec - 55.739442 Mpixels/sec
58.867574 frames/sec - 54.673848 Mpixels/sec

<empty>
# The first frame is rendered but the gears are not animated at all.

139
now initializing buffer nr. 0 of 139
now initializing buffer nr. 1 of 139
now initializing buffer nr. 2 of 139
now initializing buffer nr. 3 of 139
...
now initializing buffer nr. 138 of 139

---

Would it be possible to support --xwin for MSYS2?

In general it would be possible; I did not include it so far because it has the same features as --vcxsrv, but would need some more effort to provide it for MSYS2 and WSL.
However, if --gpu makes a big difference here, it might be worth the effort.

Unless we find out the issue with VcXsrv and NVIDIA, I think it makes a big difference. However, there might be some issue with line endings. Currently, I use MSYS2 mostly because pacman and because it allows to use bash scripts with CRLF. When I clone/pull a git repo, all the line endings are converted to CRLF automatically. Hence, in order to execute x11docker from cygwin I need to use dos2unix first.

[eine]

@mviereck, a summary of the tests:

	MSYS2 vcxsrv NVIDIA	MSYS2 vcxsrv Intel	Cygwin xwin NVIDIA	Cygwin xwin Intel
GUI	ok	ok	ok	ok
glxinfo	crash	ok	ok	ok
glxspheres	crash	ok	ok	ok
glxgears	crash	ok/slow	first frame only	ok
palinopsia	crash	ok	ok	ok
hardinfo	crash	ok	ok	ok

Test with NVIDIA cards have been executed on the workstation and on the laptop.

[eine]

@phil294, since x11docker is essentially a single bash script, it is possible to use it without cloning the repo. For example:

curl -fsSL https://raw.githubusercontent.com/mviereck/x11docker/master/x11docker \
| bash -s -- --clipboard --gpu x11docker/check

I think that this is functionally equivalent to what you would expect from a docker image.

This might not work for x11docker-gui, though.

[eine]

I tried commenting out LIBGL_ALWAYS_INDIRECT=1. On the laptop, with vcxsrv and Intel, glxinfo, glxspheres, glxgears... all of them work. However, the following message is shown in all the terminals:

libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast

With NVIDIA, it still crashes.

[phil294]

I tried --xwin and I can confirm @1138-4eb's results:

glxinfo actually prints out the nvidia gpu specs and glxspheres runs with 60 fps (probably limited? because I would expect much more) and glxgears only shows the very first frame.

I will proceed to try out other gpu accessing programs like games.

Concerning my idea of a docker-x11docker-image: Yes, I know, it would not help much: a simple batch script could achieve the same thing. However, there is no such batch script right now and I did not know there were any plans on doing so. With no batch script available and x11docker containerized, Windows users could be spared to install msys2 or cygwin. Feel free to ignore this paragraph, I should have opened a seperate issue.

[mviereck]

@1138-4eb and @phil294 , much thanks for your tests! Especially the table of @1138-4eb is quite helpful.

I did several attempts to run Xwin in MSYS2. It was a PITA in my Windows VM setup, and although I had partial success, I've dropped all the new code. It costs a lot of time to run tests, and the code gets quite complicated due to incompatibility between Cygwin and MSYS2.

Sorry, currently I can only recommend to use --xwin in Cygwin if one wants to use a NVIDIA GPU. Maybe I'll try again when I have more time for this.
I've updated the wiki entry and the x11docker message for --vcxsrv --gpu accordingly.

glxinfo actually prints out the nvidia gpu specs and glxspheres runs with 60 fps (probably limited? because I would expect much more) and glxgears only shows the very first frame.

It is a very good sign if glxgears reports 60 frames per seconds. In that case the GPU frame rate is synced to the monitor frame rate.
glxspheres64 should show 60 fps, too.

It is odd that the Intel results in #148 (comment) show high frame rates, but the NVIDIA results show 60fps.

Something seems to be wrong in the Intel result. Maybe the correct GPU is shown, but software rendering is used nonetheless? Mabe the driver does not report the correct frame rate?

[phil294]

It is a very good sign if glxgears reports 60 frames per seconds. In that case the GPU frame rate is synced to the monitor frame rate.
glxspheres64 should show 60 fps, too.

I think you misread, @mviereck: glxgears does not go beyond the first frame and glxspheres64 as about 60 frames. I also tried glxgears without --gpu and got about 400 fps (as expected).

Everything seems to work with --gpu --xwin. First game I tried was on a really bad framerate though. Will get back in a few days with further tests

[eine]

I did several attempts to run Xwin in MSYS2. It was a PITA in my Windows VM setup, and although I had partial success, I've dropped all the new code. It costs a lot of time to run tests, and the code gets quite complicated due to incompatibility between Cygwin and MSYS2.

I assume that the incompatibility arises when you try to somehow execute Cygwin from MSYS2 in order to initialize the X server. Would a two-step approach be feasible alternatively? I.e.:

• User executes an x11docker command in Cygwin and a command is shown.
• User copies the command and uses it to execute x11docker in MSYS2.

[mviereck]

The current 5.7.0-beta supports --xwin in MSYS2 and WSL.
However, this is barely tested and will be removed again during the code simplification discussed in #160 .

[mviereck]

The current master version 6.0.0-beta drops option --vcxsrv and supports --xwin (with best GPU support) in Cygwin only. For reasons compare #160.

In WSL and MSYS2 x11docker must be started with runx. Compare #165.
Maybe I'll include XWin support for WSL and MSYS2 in runx, too.
runx supports XWin in WSL, too.

Thank you for your test reports!