Good luck. Would there be any possibility of modifying the application itself such that it runs on Machine B but uses MPI to farm out its compute to Machine C?
I would also suggest not using GLXgears as a benchmark. It is completely meaningless as a test of 3D performance. I would use /opt/VirtualGL/bin/glxspheres -m instead, and use 'vglrun -sp' to run this within VirtualGL, so that frame spoiling is disabled and you get an accurate reading of the frame rate going through the VirtualGL pipeline. What that does is run GLXspheres in immediate mode, which will simulate the performance of applications that don't use display lists. I don't know whether your app does or doesn't, but many professional apps don't, and what that means in an indirect rendering environment is that every polygon has to be resent over the network for every frame. On 6/23/10 9:26 AM, Nate Fuhriman wrote: > Just an update on this > I tested the recommendation below and got 12fps with glxgears. For reference > on the actual display on machine b I get over 29000fps. > > I wrote a script that fools vglrun into thinking it is talking to X on ":0" > but is actually talking to socket on machine b over tcp. that got 80fps. > > I am working with a programmer friend. He is looking at making a modified > version of vglrun that speaks native IB calls in doing it's communication > from > machine c to machine b. I will keep you posted. > > > On Friday Friday 18 June 2010 3:10 pm DRC wrote: >> You could possibly run the application and VirtualGL on Machine C and >> display the output to Machine A via the VGL Transport or TurboVNC but >> then set VGL_DISPLAY on Machine C to the X display of Machine B, e.g.: >> >> machine_a> vglconnect machine_c >> machine_c> export VGL_DISPLAY=machine_b:0.0 >> machine_c> vglrun my_application >> >> or >> >> machine_a> ssh machine_c >> machine_c> /opt/TurboVNC/bin/vncserver >> machine_a> /opt/TurboVNC/bin/vncviewer machine_c:1 >> machine_c (in VNC session)> export VGL_DISPLAY=machine_b:0.0 >> machine_c (in VNC session)> vglrun my_application >> >> The security issues with this are numerous. You would have to enable >> X11 TCP connections on machine_b and then open up machine_b's X server >> to machine_c using xhost or create an xauth key that can shared to all >> users of machine_c. >> >> Also, this method will use an indirect OpenGL connection between >> machine_c and machine_b to do the rendering, which isn't really what >> VirtualGL was designed to do (it will complain about this.) The only >> reason why it might work OK is that the two machines are connected with IB. >> >> You may also run into issues of mismatched OpenGL client and server >> libraries. machine_c presumably has Mesa installed, whereas machine_b >> is using NVIDIA's OpenGL implementation. I don't know whether VirtualGL >> will like having to pull OpenGL functions from Mesa (this hasn't been >> tested), and I don't know whether Mesa will be able to communicate >> properly over the network to the NVIDIA libraries to do things like >> creating Pbuffers. >> >> Let me know if it works. >> >> On 6/18/10 12:27 PM, Nate Fuhriman wrote: >>> I have a the following weird situation. Can you let me know if it is >>> possible to setup virtualgl this way and if it is some basic >>> instructions on how to do it. >>> >>> I have Machine A, B, C >>> >>> Machine A is the machine with the actual monitor connected that I want to >>> see output on. >>> >>> Machine B is machine with a nvidia graphics card but not much memory and >>> comparatively slow cpus. >>> >>> Machine C has fast processors with lots of memory but no way to install >>> graphics card (Blade) >>> >>> Machine B and Machine C have QDR Infiniband connection to each other. >>> >>> Machine A has Gigabit connection over lan to machine B and C >>> >>> Is there a way to Display on machine A. have GL rendered on machine B and >>> have the application run on machine C where it has the room to do it's >>> calculations. >>> >>> Thanks in advance. >>> Nate >>> >>> ------------------------------------------------------------------------- >>> ----- ThinkGeek and WIRED's GeekDad team up for the Ultimate >>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >>> lucky parental unit. See the prize list and enter to win: >>> http://p.sf.net/sfu/thinkgeek-promo >>> _______________________________________________ >>> VirtualGL-Users mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/virtualgl-users >> >> --------------------------------------------------------------------------- >> --- ThinkGeek and WIRED's GeekDad team up for the Ultimate >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >> lucky parental unit. See the prize list and enter to win: >> http://p.sf.net/sfu/thinkgeek-promo >> _______________________________________________ >> VirtualGL-Users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > VirtualGL-Users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/virtualgl-users ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ VirtualGL-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/virtualgl-users
