Re: [VirtualGL-Users] Remote VirtualGL Server

[DRC <dco...@us...>]

Not really.  There would be issues with such a solution:

-- Compatibility:  Indirect OpenGL will not have access to a lot of 
OpenGL extensions that applications might need, and you could run into 
even more serious compatibility problems if the X proxy server and the 
3D server are not running similar OpenGL stacks (for instance, if the X 
proxy server was running Mesa and the 3D server was running nVidia.) 
When you run an application in VirtualGL, VirtualGL passes through most 
of the OpenGL calls unaltered, so the application behaves as if it is 
running locally-- with no OpenGL call overhead.

-- Performance:  The performance issues related to indirect OpenGL are 
precisely what VirtualGL was designed to circumvent.  Read the 
background article on VirtualGL.org to get a feel for what some of these 
might be, but basically, you're going to be sending all of the 3D data 
and commands (including textures, which can be a killer) across a 
network and receiving uncompressed frames back.  There is a tremendous 
amount of overhead associated with this.  Even a single user could 
monopolize all of the bandwidth of a gigabit pipe in this scenario, and 
even then, the performance would not come anywhere close to that of the 
direct rendering scenario.  In order to support such a solution in any 
reasonable fashion, we'd have to come up with some way of compressing 
the 3D data (which would require immense complexity-- instead of just 
intercepting GLX, VirtualGL would have to become a full OpenGL 
interposer.  No.  Not gonna happen) and compressing the images read back 
from the remote 3D server (which would require implementing some sort of 
daemon that would run on that server.)  There are other solutions that 
do some or all of that (DCV comes to mind), but even those solutions 
don't perform particularly well with a remote 3D server, in my testing.

I've been doing this for a while now, and it's been my experience that, 
in most cases, whenever someone says they want to host an X proxy server 
on a different machine than a 3D server, it's a problem that can be 
solved with hardware.  We have many deployments of VirtualGL and 
TurboVNC in corporations, academia, supercomputer centers, etc., and all 
of those are hosting the application and the X proxy on the same machine 
without any major hurdles.  They use beefy multi-core, multi-processor 
servers with high-end headless nVidia adapters.


On 3/13/15 8:43 PM, Jonathan Wong wrote:
> Is there a configuration where it's possible to have the X Proxy and
> application together while using a remote 3D X server for VirtualGL?
> Sort of a cross between using VirtualGL with an X Proxy on a Different
> Machine and the example with VirtualGL and chromium.
>
> Basically I have a headless, GPU-less server that I'd like to VNC to,
> but I'd also like GLX acceleration such that vgl will go through the
> remote X server. Something akin to a VMGL-like setup but with VirtualGL.
>
> Thanks,
> Jon