Yes, that is exactly what VirtualGL does, but the VirtualGL Client is
not a required component of VirtualGL.  The VirtualGL Client is only
used if you use the built-in VGL Transport, which is only useful in a
remote X environment (i.e. when the 2D X server is on the client
machine.)  Most users use VirtualGL with an X proxy these days, in which
case the VirtualGL Client is not used.

Apart from that, it sounds like what you are trying to accomplish is the
same as https://github.com/VirtualGL/virtualgl/issues/98: sharing the 3D
X server connection from host to guest in a container environment such
as Docker.

On 8/24/20 9:15 AM, Martin Pecka wrote:
> As the GPUs are shared among more users, I find it useful to give a
> separate (but still accelerated) X display to each user. I suppose
> telling everybody to use :0 wouldn't end up very well (as long as
> everyone would be rendering offscreen, it'd work, but I can't
> guarantee that). So I thought that VirtualGL could be the thing that
> would guarantee that nobody will be rendering onscreen.
>
> Dne pondělí 24. srpna 2020 v 16:02:20 UTC+2 uživatel DRC napsal:
>
>     I don't fully understand what you're proposing.  The 3D X server
>     part of
>     your proposal should be no problem, as long as you connect each
>     GPU to a
>     separate screen on that X server (presumably, the 3D X server
>     would be
>     headless.)  But why is the VirtualGL Client involved?
>
>     Conceptually, it should be possible to share the 3D X server
>     connection
>     with, say, a Docker container, but given the extremely limited
>     resources
>     of this project, I have thus far been unable to dedicate the time
>     toward
>     researching how best to accomplish that
>     (https://github.com/VirtualGL/virtualgl/issues/98).
>
>     On 8/21/20 7:44 AM, Martin Pecka wrote:
>     > Hi, we're thinking about getting GLX support on our HPC cluster
>     which
>     > (currently) is completely headless. The idea is that users
>     should be
>     > able to run virtual containers which would be given access to HW
>     > rendering with OpenGL. EGL would be better, but we're stuck with
>     OGRE
>     > rendering engine which doesn't have proper support for the
>     nvidia EGL.
>     >
>     > Could you comment on my idea? Is it a supported scenario?
>     >
>     > The multi-GPU server would run a single "3D X server", probably
>     Xorg.
>     > It would also run the virtualgl client. Containers that want to do
>     > some OpenGL stuff would call a combination of xvfb and vglrun. I.e.
>     > the whole setup only works with a single machine, not a pair
>     connected
>     > via ssh -X.
>     >
>     > Is that possible? Is there a tutorial for this kind of setup?
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "VirtualGL User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to [email protected]
> <mailto:[email protected]>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/virtualgl-users/3973b3c2-f7ef-41b6-a580-14941b846b96n%40googlegroups.com
> <https://groups.google.com/d/msgid/virtualgl-users/3973b3c2-f7ef-41b6-a580-14941b846b96n%40googlegroups.com?utm_medium=email&utm_source=footer>.

-- 
You received this message because you are subscribed to the Google Groups 
"VirtualGL User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/virtualgl-users/cd1abb94-fbc1-0328-a582-57c8641ca67d%40virtualgl.org.

Reply via email to