glFlush() in VirtualGL won't do anything (other than pass a glFlush() down to the OpenGL system) unless something is being rendered to the front buffer. In that case, glFlush() performs a pixel readback, contingent on the afore-mentioned throttling mechanism. The glFlush() throttling mechanism was introduced because some CAD applications would use front buffer rendering for wireframe drawing and would generate a glFlush() call for every line in the drawing. This could equate to multiple thousands of calls to glFlush() for every frame drawn. If VirtualGL detects that back-to-back glFlush() calls are occurring at a rate of more than 100 per second, it will temporarily introduce a 1/100 second delay into the compress thread. This is designed to trigger the frame spoiling mechanism to spoil the frames generated from the many glFlush() calls rather than performing a readback for each one. The delay is canceled whenever the app calls glXSwapBuffers(), glFinish(), or glXWaitGL(), or if two back-to-back glFlush() calls occur at a rate slower than 100 per second.
The first thing I'd try is to enable tracing in VirtualGL (vglrun +tr) and get a sense of how many glFlush() calls are being made for each frame and whether front buffer rendering is in fact enabled. Next, try commenting out the call to _doGLreadback() in VirtualGL's version of glFlush() and see if that improves performance and whether it causes visual anomalies. On 3/18/10 2:05 PM, Karl Vogel wrote: > I have been happily using VirtualGL the last couple of months to run a > game under Wine and retarget the display to my OpenGL challenged laptop. > > This worked fine until recently where a wine update caused my laptop to > almost completely lock when the game started. While the fact that my > laptop becomes unresponsive (well the X server) is hardly VirtualGL's > fault, it is the trigger. > > I've tracked down the patch that is causing the extreme slowdown when > running wine with VirtualGL. The patch in question is: > > --- > commit ce42470138a4805dce509a1fa806c8880530f324 > Author: Henri Verbeet <[email protected]> > Date: Wed Jan 27 20:19:40 2010 +0100 > > wined3d: Ensure draw ordering across contexts. > --- > http://source.winehq.org/git/wine.git/?a=commitdiff;h=ce42470138a4805dce509a1fa806c8880530f324 > > > It seems to sprinkle a few glFlush() calls throughout the pipeline. I > did notice in the virtualgl sources that the glFlush() call is already > throttled, but it seems that this isn't sufficient for the wine+vgl combo. > > Was wondering if there is any solution to this issue?! > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > VirtualGL-Users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/virtualgl-users ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ VirtualGL-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/virtualgl-users
