Closed ptr33 closed 2 years ago
There is no gl support at all. It's not just a matter of linking in a video device and installing drivers it is xrdp level for opengl support. Some distros have packages like Arch but for Ubuntu/alpine we would need to compile in detect and handle perms etc. In general we are kind of in a holding pattern for this implementation to improve a bit to implement this across our rdesktop base images in a universal fashion.
Thank you @thelamer for the review. Nevertheless I am wondering about the comment as I have glx running inside the docker container.
I am using a container FROM ghcr.io/linuxserver/rdesktop:mate-focal and added RUN usermod -a -G render abc
In the Dockerfile I used
devices:
- /dev/dri:/dev/dri # GPU support
I have a Intel Iris Plus Graphics 655 and this now works inside container
abc@f4ab7fc03f6f ~ $ glxheads :10.0
Name: :10.0
Display: 0x55c7e6e78d80
Window: 0x600002
Context: 0x55c7e6eac970
GL_VERSION: 4.6 (Compatibility Profile) Mesa 21.2.6
GL_VENDOR: Intel
GL_RENDERER: Mesa Intel(R) Iris(R) Plus Graphics 655 (CFL GT3)
So I think glx is supported with this minor addition. Thank you
I'm confused are you seeing the triangle ? Xrdp and vnc has conventionally required virtualgl redirection. CLI stuff will work like gpu video encoding etc, but actual graphical rendering does not due to a software framebuffer being used.
Hi @thelamer ,
I have a RDP connection from windows to a linux box running the docker server and glxheads renders the triangle with GPU support:
I also see that the GPU is used as intel_gpu_top (I execute this command on the server directly not inside the docker container) shows the activity:
intel-gpu-top - 359/ 364 MHz; 0% RC6; 2.35 Watts; 761 irqs/s
IMC reads: 1441 MiB/s
IMC writes: 1179 MiB/s
ENGINE BUSY MI_SEMA MI_WAIT
Render/3D/0 16.63% |████████████▊ | 0% 0%
Blitter/0 0.00% | | 0% 0%
Video/0 0.00% | | 0% 0%
Video/1 0.00% | | 0% 0%
VideoEnhance/0 0.00% | | 0% 0%
I also see GPU activity when I simply move the windows inside the docker container xrdp session.
Thank you
I will look back into this, but it was my understanding this would not work without virtualgl. For testing can you run this on two containers at once ?
Yes, I can run this in two separate containers simultaneously:
both container are derived rdesktop:mate-focal
FROM ghcr.io/linuxserver/rdesktop:mate-focal
...
RUN usermod -a -G render abc
Thanks
@ptr33 no joke you just blew my mind.
https://user-images.githubusercontent.com/1852688/156831786-5d40b1e4-a9c9-4f7b-a3da-dcdd4bcce389.mp4
We use these base images for a whole world of desktop app images including webtop. I need to polish the perm automation and get drives into our baseimages for Arch, Alpine, Fedora, and Ubuntu so it may take a bit, but I will ping you when this is implemented.
@thelamer thank you!
This is in the latest images simply pass --device=/dev/dri:/dev/dri
and it should work.
I need to reformat and retag the images in this repo to bring them in line with https://github.com/linuxserver/docker-webtop
along with that will be documentation for this.
Thank you @thelamer for your fast response, it perfectly works - I tested it with ghcr.io/linuxserver/rdesktop:mate-focal and adding /dev/dri to devices in Dockerfile and my Intel GPU is used inside the docker container.
docker-rdesktop does not use Intel GPU
Expected Behavior
If an Intel GPU is installed in the system, the xrdp server of docker-rdesktop should use it.
Current Behavior
docker-rdesktop always uses software rendering.
Steps to Reproduce
Environment
OS: Linux / Ubuntu 20.04 CPU architecture: x86_64 How docker service was installed: sudo apt install docker.io
use following Dockerfile command to solve the issue - the problem is access rights for /dev/dri RUN usermod -a -G render abc