I also wanted to answer your question regarding GLXgears running "choppy." It's doing that because you're redirecting the 3D images across the network in an uncompressed form. It would be much smoother if you used JPEG compression and the VGL Transport (that is, if you didn't specify '-c proxy'), but since your ultimate goal is not to display the 3D app to a remote machine, that's a bit of a moot point. As far as the disparity in frame rates, it's because VGL has frame spoiling turned on by default, so the benchmark is not measuring the actual server/client frame rate but rather the rate at which the 3D images are rendered by the app and read back into main memory by VirtualGL. 'vglrun -sp' disables frame spoiling and allows the benchmark to measure the server/client frame rate (see Section 18.2), but even then, GLXgears isn't a good benchmark to use for this. Use GLXspheres instead. GLXgears has too simple a geometry, and the images it generates have too much solid color and are thus too easily compressible to be a good test of remote display systems.
On 11/29/12 1:49 AM, DRC wrote: > Re-read Chapters 8 and 9. vglconnect is used only for the VGL > Transport, which compresses the 3D images and forwards them to a remote > X server. That isn't what you want, and in fact, by also specifying '-c > proxy' as arguments to vglrun, you are bypassing the VGL Transport on > the server end and instead causing VirtualGL to send the 3D images > uncompressed to the remote X server, which definitely isn't what you want. > > You simply need to use the same vglrun command line you're using below, > but type it *after* you do 'export DISPLAY=localhost:1.0'. When using > the X11 Transport (-c proxy), VirtualGL basically causes the 3D app to > act like a 2D X11 app, so it uses DISPLAY the same way any X11 app would. > > The message about being unable to load libdlfaker.so and librrfaker.so > is a problem, though. Make sure those libraries are installed in a > system library path (for instance, /usr/lib) or that the path in which > they're installed is in LD_LIBRARY_PATH. That message generally means > that VirtualGL has not been loaded successfully, so it probably won't > work until you resolve that issue. That message can also mean that > you're running a 3D app that has setuid root permissions, in which case > you need to read Chapter 13, but it would be odd for glxgears to be > setuid root. > > > On 11/29/12 12:19 AM, charles quarra wrote: >> 2012/11/27 DRC <dcomman...@users.sourceforge.net>: >>> On 11/27/12 2:25 PM, charles quarra wrote: >>>> Because i'm thinking that you need turboVNC in order to composite >>>> the 3d >>>> renderings inside the application windows? Are you saying that i can >>>> use >>>> virtualGL to render remote apps (i.e: some 3d game) and then >>>> redirect the output >>>> to Xvfb without using turboVNC? >>> >>> Yes. >>> >>> >> >> This is great news. So i've already set up to run in the server with >> ATI HD6800 hardware, and installed it in a few testing machines on the >> LAN to behave as clients >> >> >> i followed the documentation, first did vlgconnect to the server, then >> i did >> vlgrun -c proxy -fps 10 -- VirtualGL/bin/glxgears >> >> this starts the window while connected over ssh to the server. My >> question is, how do i direct this app inside the xvfb running on the >> client machine? >> >> usually the process to run something inside Xvfb is like: >> >> 1) start Xvfb: >> Xvfb :1 -screen 0 1024x768x24 -fbdir vfb_test/fbdir & >> >> 2) set default display >> export DISPLAY=localhost:1.0 >> >> 3) start app >> xterm -e '/usr/X11/bin/xcalc' & >> >> What would i need to change in how i start the glxgears sample so that >> it will run inside Xvfb? >> >> >> P.S: not related to this question, but vlgrun glxgears runs a bit >> choppy on the client, and it reports high FPS (apparently ignoring the >> -fps option) >> >> this is the output >> >> ERROR: ld.so: object 'libdlfaker.so' from LD_PRELOAD cannot be >> preloaded: ignored. >> ERROR: ld.so: object 'librrfaker.so' from LD_PRELOAD cannot be >> preloaded: ignored. >> Visual ID: 0xd3 >> 18477 frames in 5.2 seconds = 3533.601 FPS >> 3470 frames in 5.3 seconds = 652.749 FPS >> >> ------------------------------------------------------------------------------ >> >> Keep yourself connected to Go Parallel: >> VERIFY Test and improve your parallel project with help from experts >> and peers. http://goparallel.sourceforge.net >> _______________________________________________ >> VirtualGL-Users mailing list >> VirtualGL-Users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/virtualgl-users >> ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
