Thanks for linking me to the background reading, that was very educational. 
I see that I can use VirtualGL Transport to call my GL applications without 
a remote desktop, but this will introduce latency between the client-side 
2D X server, and the remote 3D X server. Perhaps a startup script on the 
client which  transparently launches a remote desktop to the TurboVNC 
server is a better solution, because the 3D and 2D X servers have access to 
the same shared memory for PBuffer swaps. Did I understand the advantage of 
the X proxy correctly? Collaborative visualization is not a concern for me, 
but the X proxy seems like a better solution in any case.

Regarding the modifications to VirtualGL which would obviate the 3D X 
server; in the background reading you mention:

... the application must still use indirect OpenGL rendering to send 3D 
> commands and data to the X proxy. It is, of course, much faster to use 
> indirect rendering over a local socket rather than a remote socket, but 
> there is still some overhead involved.

 Is the 3DX to 2DX chatter the bottleneck, is the gigabit network the 
bottleneck, or are they cumulative bottlenecks?

You mentioned a few open and closed source solutions like TurboVNC, and I 
noticed you did not mention NVIDIA's own remote visualization solutions, 
GeForce Experience and the Moonlight client. Remote visualization + GL 
capability appears to be an area where NVIDIA should be leading, but it 
seems they are I wrong? I do not work for NVIDIA so speak freely, 

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 view this discussion on the web visit
For more options, visit

Reply via email to