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 ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
