[Caution: Email from External Sender. Do not click or open links or attachments unless you know this sender.]
--
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 virtualgl-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/d4256049-e3e7-40ab-97b8-634fc69a38e4n%40googlegroups.com.
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.
--
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 virtualgl-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/3973b3c2-f7ef-41b6-a580-14941b846b96n%40googlegroups.com.
I don't understand how you plan to get the rendered pixels from the X proxy to the client machine. Xvfb won't do that. You would need an X proxy that has an image transport layer attached (TurboVNC, as an example, is essentially Xvfb with an attached VNC server.) I also don't understand why you're still mentioning vglclient, since that has no relevance to the server-side configuration. I can almost guarantee you that the technical specifics you listed below are not correct, but in order to correct them, I need a better understanding of what you are ultimately trying to accomplish. Let's bring the discussion up a level and develop a mutual understanding of the proposed solution architecture before we get mired down in the specifics of command lines and environment variables and such.
I'm not sure, for instance, what you are expecting in terms of a window popping up. That will never happen on the 3D X server, since VirtualGL is redirecting all OpenGL rendering into off-screen Pbuffers. It would only happen on the 2D X server, but again, if you're trying to use Xvfb as a 2D X server, then I don't understand how you expect to get the pixels from that X server to the client machine without an image transport layer. Also, unless you change the DISPLAY environment variable, the application will not display to the Xvfb instance anyhow.
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/d4c5899e-c602-4dc6-bf14-4a9d695255fan%40googlegroups.com.
OK. In that case, your general strategy will be:
- On the host, set up the headless 3D X server on Display :0 with each GPU attached to a different screen.
- Figure out how to share the 3D X server connection from the host to a container instance. My first approach would be to try sharing the files related to the 3D X server's Unix domain socket. Again, I have not personally experimented with this yet, so I do not yet know what issues might be encountered.
- To launch an application in a container instance:To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/d915ad0f-010b-4155-98f3-10147f589256n%40googlegroups.com.