| View previous topic :: View next topic |
| Author |
Message |
curmudgeon
Veteran
Joined: 08 Aug 2003
Posts: 1741
|
 Posted: Tue Sep 05, 2023 1:56 pm Post subject: running opengl / sdl apps remotely |
 |
|
Does anyone know how to remotely (via ssh) run apps that use opengl and /or sdl?
My attempts produce various error messages:
| Code: |
$ eglinfo -B
GBM platform:
EGL API version: 1.5
EGL vendor string: Mesa Project
EGL version string: 1.5
EGL client APIs: OpenGL OpenGL_ES
OpenGL core profile vendor: Intel
OpenGL core profile renderer: Mesa Intel(R) HD Graphics 2500 (IVB GT1)
OpenGL core profile version: 4.2 (Core Profile) Mesa 23.0.3
OpenGL core profile shading language version: 4.20
OpenGL compatibility profile vendor: Intel
OpenGL compatibility profile renderer: Mesa Intel(R) HD Graphics 2500 (IVB GT1)
OpenGL compatibility profile version: 4.2 (Compatibility Profile) Mesa 23.0.3
OpenGL compatibility profile shading language version: 4.20
OpenGL ES profile vendor: Intel
OpenGL ES profile renderer: Mesa Intel(R) HD Graphics 2500 (IVB GT1)
OpenGL ES profile version: OpenGL ES 3.0 Mesa 23.0.3
OpenGL ES profile shading language version: OpenGL ES GLSL ES 3.00
X11 platform:
*****libEGL warning: DRI2: failed to authenticate***** (emphasis added)
EGL API version: 1.4
EGL vendor string: Mesa Project
EGL version string: 1.4
EGL client APIs: OpenGL OpenGL_ES
OpenGL core profile vendor: Mesa
OpenGL core profile renderer: softpipe
OpenGL core profile version: 3.3 (Core Profile) Mesa 23.0.3
OpenGL core profile shading language version: 3.30
OpenGL compatibility profile vendor: Mesa
OpenGL compatibility profile renderer: softpipe
OpenGL compatibility profile version: 3.3 (Compatibility Profile) Mesa 23.0.3
OpenGL compatibility profile shading language version: 3.30
OpenGL ES profile vendor: Mesa
OpenGL ES profile renderer: softpipe
OpenGL ES profile version: OpenGL ES 3.1 Mesa 23.0.3
OpenGL ES profile shading language version: OpenGL ES GLSL ES 3.10
[...]
$ glxgears
Error: couldn't get an RGB, Double-buffered visual
$ scrcpy
scrcpy 2.1.1 <https://github.com/Genymobile/scrcpy>
INFO: ADB device found:
INFO: --> (tcpip) 192.168.0.2:5555 device [redacted]
/usr/share/scrcpy/scrcpy-server: 1 file pushed, 0 skipped. 4.0 MB/s (56995 bytes in 0.013s)
[server] INFO: Device: [redacted]
[server] WARN: Audio disabled: it is not supported before Android 11
ERROR: Could not create renderer: Couldn't find matching render driver
|
Searching didn't really produce anything useful, and I hope that someone here has first-hand experience with this.
Last edited by curmudgeon on Tue Sep 05, 2023 6:01 pm; edited 1 time in total |
|
| Back to top |
|
 |
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3140
|
| Posted: Tue Sep 05, 2023 3:27 pm Post subject: |
|
|
AFAIK both those tihngs are accessed via X server, so you must connect to it in some way.
Ssh offers x11 forwarding. Check out -X and -Y in man ssh. This will connect your remote application to your local X-server.
If you want to use remote machines's xserver, it should be possible if you set DISPLAY= before running your program, (there may be other conditions you have to meet), but this will not let you tunnel gui over ssh session, probably making the whole exercise pointless. In order to borrow remote machine's GPU, use remote desktop instead of ssh. SPICE is pretty convenient.
You can secure spice connection by tunneling in via ssh session, see -L for port forwarding. |
|
| Back to top |
|
|
curmudgeon
Veteran
Joined: 08 Aug 2003
Posts: 1741
|
| Posted: Tue Sep 05, 2023 5:59 pm Post subject: |
|
|
| szatox wrote: | AFAIK both those tihngs are accessed via X server, so you must connect to it in some way.
Ssh offers x11 forwarding. Check out -X and -Y in man ssh. This will connect your remote application to your local X-server. |
I have run (non opengl / sdl) applications remotely for more than a quarter century. In fact, I have four such applications open right now.
| szatox wrote: | | If you want to use remote machines's xserver, it should be possible if you set DISPLAY= before running your program, (there may be other conditions you have to meet), but this will not let you tunnel gui over ssh session, probably making the whole exercise pointless. |
That makes no sense (the DISPLAY variable becomes part of the environment, and does not require declaration before running a program, and the display does get tunneled over ssh. As far as "there may be other conditions you have to meet," I asked this question to learn those, as I obviously have something misconfigured. :)
More output from commands:
| Code: |
$ glxinfo | grep rendering
Error: couldn't find RGB GLX visual or fbconfig
$ mpv some.file
(+) Video --vid=1 (*) (h264 1280x720 30.000fps)
(+) Audio --aid=1 --alang=eng (*) (aac 2ch 44100Hz)
libEGL warning: DRI2: failed to authenticate
[vo/gpu/x11] X11 error: BadRequest (invalid request code or no such operation)
[vo/gpu/x11] Type: 0, display: 0x7f5420049810, resourceid: 256, serial: 25
[vo/gpu/x11] Error code: 1, request code: 98, minor code: 1
[vo/gpu/opengl] Suspected software renderer or indirect context.
[vo/gpu/opengl] no GLX support present
[vo/gpu/drm] VT_GETMODE failed: Inappropriate ioctl for device
[vo/gpu/drm] Failed to set up VT switcher. Terminal switching will be unavailable.
[vo/gpu/drm] Failed to acquire DRM master: Permission denied
[vo/gpu/drm] Failed to commit ModeSetting atomic request: Permission denied
[vo/gpu/opengl] Failed to set CRTC for connector 87: Permission denied
[vo/gpu] Failed to commit atomic request: Permission denied
[vo/gpu/drm] Failed to commit ModeSetting atomic request: Permission denied
[vo/gpu/drm] Failed to restore previous mode
[vo/gpu/drm] Failed to drop DRM master: Permission denied
MESA-INTEL: warning: Ivy Bridge Vulkan support is incomplete
[vo/gpu/libplacebo] Found no suitable device, giving up.
[vo/gpu/libplacebo] Failed initializing vulkan device
MESA-INTEL: warning: Ivy Bridge Vulkan support is incomplete
libEGL warning: DRI2: failed to authenticate
[vo/gpu-next/x11] X11 error: BadRequest (invalid request code or no such operation)
[vo/gpu-next/x11] Type: 0, display: 0x7f542007e0f0, resourceid: 256, serial: 25
[vo/gpu-next/x11] Error code: 1, request code: 98, minor code: 1
[vo/gpu-next/opengl] Suspected software renderer or indirect context.
[vo/gpu-next/opengl] no GLX support present
[vo/gpu-next/drm] Can't handle VT release - signal already used
[vo/gpu-next/drm] Failed to set up VT switcher. Terminal switching will be unavailable.
[vo/gpu-next/drm] Failed to acquire DRM master: Permission denied
[vo/gpu-next/drm] Failed to commit ModeSetting atomic request: Permission denied
[vo/gpu-next/opengl] Failed to set CRTC for connector 87: Permission denied
[vo/gpu-next] Failed to commit atomic request: Permission denied
[vo/gpu-next/drm] Failed to commit ModeSetting atomic request: Permission denied
[vo/gpu-next/drm] Failed to restore previous mode
[vo/gpu-next/drm] Failed to drop DRM master: Permission denied
MESA-INTEL: warning: Ivy Bridge Vulkan support is incomplete
[vo/gpu-next/libplacebo] Found no suitable device, giving up.
[vo/gpu-next/libplacebo] Failed initializing vulkan device
MESA-INTEL: warning: Ivy Bridge Vulkan support is incomplete
[vo/xv] Warning: this legacy VO has bad quality and performance, and will in particular result in blurry OSD and subtitles. You should fix your graphics drivers, or not force the xv VO.
AO: [alsa] 48000Hz stereo 2ch float
VO: [xv] 1280x720 yuv420p
[vo/xv] Shared memory not supported
[vo/xv] Reverting to normal Xv.
[vo/xv] Shared memory not supported
[vo/xv] Reverting to normal Xv.
[...]
|
|
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21651
|
| Posted: Tue Sep 05, 2023 7:02 pm Post subject: |
|
|
| I believe szatox was noting that you can ssh into a machine, then (re)set DISPLAY to point to the display of the remote machine's console X server, then start an X11 application and have it display on that remote console, not over the ssh tunnel. In that case, your XAUTHORITY may not be set up correctly for it to work on its own. For your seemingly intended use case of rendering on the machine running the ssh client, this is not helpful. However, if your application can usefully work anyway (perhaps it autostarts all its assigned work, and the GUI is just for people who want to watch it work), this might be adequate. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3140
|
| Posted: Tue Sep 05, 2023 7:04 pm Post subject: |
|
|
Alright, it seems we're talking about different things, so what are you actually trying to do?
Your terminal is on machine A, application is running on machine B, which GPU are you trying to use? |
|
| Back to top |
|
|
steve_v
Guru
Joined: 20 Jun 2004
Posts: 388
Location: New Zealand
|
| Posted: Tue Sep 05, 2023 9:50 pm Post subject: |
|
|
While we wait for an answer on that, perhaps virtualgl is an option? I've been using it for many years, with both SSH forwarding and X2go/NX (which lack modern GLX). Works for apps using EGL and/or expecting direct access to a GPU/DRM too.
IME it's often more efficient to use the server's GPU rather than indirect (GLX) rendering and sending all the draw calls over SSH anyway. The link has a pretty good overview of the various options for remote 3D rendering in general.
_________________
Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy. |
|
| Back to top |
|
|
curmudgeon
Veteran
Joined: 08 Aug 2003
Posts: 1741
|
| Posted: Tue Sep 05, 2023 11:24 pm Post subject: |
|
|
| Hu wrote: | | I believe szatox was noting that you can ssh into a machine, then (re)set DISPLAY to point to the display of the remote machine's console X server, then start an X11 application and have it display on that remote console, not over the ssh tunnel. In that case, your XAUTHORITY may not be set up correctly for it to work on its own. For your seemingly intended use case of rendering on the machine running the ssh client, this is not helpful. However, if your application can usefully work anyway (perhaps it autostarts all its assigned work, and the GUI is just for people who want to watch it work), this might be adequate. |
Now I understand. I want to do the classic ssh from machine a to b, run a opengl / sdl app on machine b (using the GPU of machine b), and observe (and control) the output from machine a. Displaying the output on machine b wouldn't work in my case, although it sounds interesting. Out of curiosity, I tested attempts to do that, but they encountered many of the same error messages (authentication problems) as attempting to forward the display over the ssh connection.
| steve_v wrote: | While we wait for an answer on that, perhaps virtualgl is an option? I've been using it for many years, with both SSH forwarding and X2go/NX (which lack modern GLX). Works for apps using EGL and/or expecting direct access to a GPU/DRM too.
IME it's often more efficient to use the server's GPU rather than indirect (GLX) rendering and sending all the draw calls over SSH anyway. The link has a pretty good overview of the various options for remote 3D rendering in general. |
I had never heard of virtualgl, and will have to look at it. It does appear promising. |
|
| Back to top |
|
|
curmudgeon
Veteran
Joined: 08 Aug 2003
Posts: 1741
|
| Posted: Thu Sep 07, 2023 2:20 am Post subject: |
|
|
| szatox wrote: | | In order to borrow remote machine's GPU, use remote desktop instead of ssh. SPICE is pretty convenient. |
After a cursory look at this, it appears that spice requires a qemu virtual machine. To clarify further, I want a solution that only runs a program on machine b.
I do not want to run a virtual machine. I do not want to run a docker container. I don't want to run a remote desktop unless I can do that completely separate from the display that someone sitting that machine b would see. Other than (minimized) performance issues, a user at machine b should not have any indication of programs run this way (nothing nefarious here - just that the person at machine b gets cranky when noticing that computing resources consumed remotely reduces the responsiveness of machine b). |
|
| Back to top |
|
|
steve_v
Guru
Joined: 20 Jun 2004
Posts: 388
Location: New Zealand
|
| Posted: Thu Sep 07, 2023 8:36 am Post subject: |
|
|
| curmudgeon wrote: | it appears that spice requires a qemu virtual machine...
I do not want to run a virtual machine. I do not want to run a docker container. |
Indeed. For whatever reason once people start using VMs, every problem starts looking like one to be solved with VMs. 
| curmudgeon wrote: | | I don't want to run a remote desktop unless I can do that completely separate from the display that someone sitting that machine b would see. |
Well, that is how most *nix remote desktop solutions work anyway. It's actually more of a PITA to shadow the physical desktop with X11 or VNC than it is to start a dedicated server.
This approach actually has some benefits over X11 seamless windows, primarily the ability to reconnect and resume a session. Xpra kind of melds the two, ala "screen for X", but while it is very capable I find it a bit clunky to use.
Concepts involved in getting opengl working for either option (VNC or X based "remote desktop" and traditional X "seamless windows") are pretty well explained in the virtualgl link I posted earlier, and setup notes for virtualgl with X11 forwarding, VNC, and Xpra are on the arch wiki.
Personally I usually use X2go (because laziness and inertia), which supports both (and physical display shadowing as well) and works well enough for my needs as an X proxy (albeit with lower performance than vgl transport or turbovnc) for virtualgl. Just run gl-using remote app with 'vglrun <app>'.
To return to your OP, if you just want something as close as possible to your normal X11 fowarding over SSH but with opengl support, the virtualgl with X11 forwarding route (arch wiki, section 2) is simple and effective.
_________________
Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3140
|
| Posted: Thu Sep 07, 2023 9:48 am Post subject: |
|
|
| curmudgeon wrote: | | szatox wrote: | | In order to borrow remote machine's GPU, use remote desktop instead of ssh. SPICE is pretty convenient. |
After a cursory look at this, it appears that spice requires a qemu virtual machine. To clarify further, I want a solution that only runs a program on machine b.
I do not want to run a virtual machine. I do not want to run a docker container. I don't want to run a remote desktop unless I can do that completely separate from the display that someone sitting that machine b would see. |
While providing an interface fo a VM at supervisor level is the most common case, it's not required. And running a VM to access gpu would be a pretty dumb idea 
I needed to give remote desktop to a user who was not supposed to access supervisors. Ended up hooking spice into the xserver inside guest. It was running under qemu, because this is was we were using for slicing resources, but qemu was not involved in screen sharing.
Too bad, I it's been years ago and I no longer remember how exactly I did it other than it required writing xorg.conf to enable. There's xspice, and there are also vnc servers and i think even vnc plugins for xorg.
Spice, vnc, and virtualgl are pretty much the same concept though, so pick whatever.
The good thing about spice is that it allows clipboard sharing between user terminal and application server. The bad thing about vnc is that it was ugly (and copy-paste didn't work). Never used virtualgl. |
|
| Back to top |
|
|
paoletto
n00b
Joined: 12 Apr 2024
Posts: 1
|
| Posted: Fri Apr 12, 2024 1:18 pm Post subject: |
|
|
| steve_v wrote: | While we wait for an answer on that, perhaps virtualgl is an option? I've been using it for many years, with both SSH forwarding and X2go/NX (which lack modern GLX). Works for apps using EGL and/or expecting direct access to a GPU/DRM too.
IME it's often more efficient to use the server's GPU rather than indirect (GLX) rendering and sending all the draw calls over SSH anyway. The link has a pretty good overview of the various options for remote 3D rendering in general. |
Hi, sorry for semi.-necro posting. I'm trying it now for the first time, to run an OpenGL 4.5 app from within NX. only egl backend seems to work, but also it seems to produce only a 3.0 compatible context.
HW is intel graphics, and has up to OGL4.6 support.
Any idea how to run it so that it has higher GL support?
/opt/VirtualGL/bin/eglinfo reports
| Code: |
[...]
EGL version: 1.4
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Iris(R) Plus Graphics 655 (CFL GT3)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.0.8
[...]
|
while vglrun glxinfo reports
| Code: |
name of display: :1001
display: :1001 screen: 0
direct rendering: Yes
server glx vendor string: VirtualGL
server glx version string: 1.4
server glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile,
GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float,
GLX_ARB_get_proc_address, GLX_ARB_multisample,
GLX_EXT_create_context_es2_profile, GLX_EXT_fbconfig_packed_float,
GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_swap_control,
GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating,
GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_make_current_read,
GLX_SGI_swap_control
client glx vendor string: VirtualGL
client glx version string: 1.4
client glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile,
GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float,
GLX_ARB_get_proc_address, GLX_ARB_multisample,
GLX_EXT_create_context_es2_profile, GLX_EXT_fbconfig_packed_float,
GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_swap_control,
GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating,
GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_make_current_read,
GLX_SGI_swap_control
GLX version: 1.4
GLX extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile,
GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float,
GLX_ARB_get_proc_address, GLX_ARB_multisample,
GLX_EXT_create_context_es2_profile, GLX_EXT_fbconfig_packed_float,
GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_swap_control,
GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating,
GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_make_current_read,
GLX_SGI_swap_control
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Iris(R) Plus Graphics 655 (CFL GT3)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.0.8
OpenGL core profile shading language version string: 4.60
[...]
|
yet my (qt) app complains that
| Code: |
QOpenGLShader::compile(Vertex): 0:2(10): error: GLSL 4.50 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.40, 1.00 ES, and 3.00 ES
|
although i'm requesting a core 4.5 context..[/code] |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Desktop Environments
