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
|
