0

for my job, we are searching for an application which allows us to do export display. The specifications are :

  • clients use Windows/Linux System
  • server is a Linux Red-Hat 6 cluster
  • there are OpenGL based applications on server side. they must be running fast on client, at least as much as possible
  • the GPU are on server side. Users open a visualization session on cluster which allocates specific nodes with GPU.

For the moment, we use TurboVNC ( with a vnc client called "vncviewer" and securised by ssh tunnel ) and virtualGL on server for launching OpenGL applications (type paraview) with "vglrun name_application" command.

Could someone give me advices for alternative solutions ?

I saw XDCMP solution but it is not securised. We can't use ssh X forwarding because it is tool slow.

By the way, what is the proportion for export display, between the ressources allocating by the client and ressources allocated by the server ?

TurboVNC seems to allocate more resources on server : does it mean that client does not manage graphics processing and only receives raw data from the server, which are displaying on client side ?

Then, this would not be the case when I do a "ssh -X" ? (this should be the client which deals locally with OpenGL processing)

genpfault
  • 51,148
  • 11
  • 85
  • 139

1 Answers1

1

How long are you willing to wait to put this into production?

Right now the Linux graphics stack is built around Xorg. And Xorg has the inconvenient drawback, that you can't run purely off-screen X servers that make use of the GPU. If you can live with only one user making use of the GPU and the GPU holding the VT then you might want to look into Xpra which you start with a X server configuration that uses the GPU instead of the dummy driver.

If you're willing to wait another two years (hopefully) all drivers will fully support KMS and the DRM kernel interfaces; as much as I dislike certain aspects of Wayland, it's also a huge game changer that puts a lot of peer pressure on NVidia to finally get around and use the "standard" APIs. Already now you can use libgbm to create purely off-screen OpenGL render contexts with GPUs that support it and no display server running; i.e. GPUs with open source drivers in the Mesa3D tree (Intel and AMD, however for now just OpenGL-3 and no OpenCL). Give it another 2 years and the APIs and tools will have stabilized that you can use this conveniently in production.

Ali_Sh
  • 2,667
  • 3
  • 43
  • 66
datenwolf
  • 159,371
  • 13
  • 185
  • 298
  • OpenGL applications work fine with xpra too: http://xpra.org/trac/wiki/Usage/OpenGL And you can use the GPU with the dummy driver via vglrun – totaam Jul 01 '15 at 13:56
  • @totaam: I know, BT;DT, but the stability of this varies greatly with each Xpra release. The past few months I've actually resorted to use x11vnc instead, despite its abysmal bandwidth requirements.The problem with VirtualGL is, that it doesn't support the most modern features, which are (unfortunately for me) what I need in the very applications I do remote operations with. – datenwolf Jul 01 '15 at 14:11
  • not aware of any major problems with xpra, so unlikely to get fixed! - sounds like your problems are vgl related and not xpra? have you reported them there? – totaam Jul 02 '15 at 02:07
  • @totaam: Problems are totally Xpra related as in: Can't even establish a stable connection with some versions and the X server (Xpra xvfb process) gets immediately reset when the client is dropped. Haven't anaylzed it in depth and hence made no report yet. – datenwolf Jul 02 '15 at 06:50
  • ah, ok - sounds distro or configuration related as no-one has ever reported such problems – totaam Jul 02 '15 at 07:11