Copying my findings to the list in case someone might be googling for a solution to this or in case this same thing might be occurring in other apps:
It appears that this is a situation in which the application is doing some rather odd things that it can usually get away with but which happen to cause interaction problems when used with VirtualGL and TurboVNC. Apparently someone realized this, which is why the behavior was changed in TecPlot 2012. The app is basically doing single-buffered (front buffer) drawing, and it relies on the fact that the drawing speed will generally be fast enough on modern hardware that when it clears the front buffer and immediately redraws it using a valid image, the clear operation won't be visible to the human eye. At least, that's what appears to be happening. The app is also relying on the fact that glFlush() is an asynchronous command, whereas glFinish() is synchronous. When an app calls glFlush(), it flushes the OpenGL command buffers, which guarantees that everything rendered prior to that point will be drawn to the screen in a finite time period, but the glFlush() call doesn't actually wait for the rendering to occur before it returns control to the application. glFinish() does. VirtualGL has to treat glFlush() a bit oddly. It can't ignore it, because some applications actually don't ever call glFinish(), so VirtualGL has to assume that when an application calls glFlush() that it expects the front buffer to be drawn to the screen (or, in VirtualGL's case, to be read back and sent to the client.) However, many applications also assume that glFlush() is a free operation, so VirtualGL can't read back and send the framebuffer upon every single glFlush() command if they are occurring in very rapid progression. It thus employs a different type of frame spoiling algorithm called "spoil last", such that the framebuffer is only actually read back and sent on a glFlush() command if there is no frame already in the queue and if the last glFlush() command occurred at least 10 ms ago. In the case of TecPlot, this still results in some readbacks occurring as a result of glFlush() commands. These readbacks are redundant and unnecessary, since TecPlot also calls glFinish() to signal that it has finished rendering the frame. There is another wrinkle to this problem, which is that it only occurs when using TurboVNC. If, for instance, you use vglrun on the local display just as a sanity check, the problem doesn't occur, nor does it occur when using the VGL Transport (vglconnect/vglclient.) I thought at first that it might be related to the backing store in the X server, so I tried disabling that (passing -bs to vncserver), but that didn't work. Further, running the same thing with RealVNC 4.1.2 works fine, even with backing store enabled. Without further in-depth analysis, I can't say for sure, but it is my belief that VirtualGL is drawing the same thing to both X servers (TurboVNC and RealVNC/X.org), but for whatever reason, the RealVNC code doesn't trigger a framebuffer update until the "final" image is drawn for each frame. This may be simply a difference in how it handles the deferred update timer or something like that. In any case, even if the app did display properly in TurboVNC, that doesn't change the fact that reading back the frames that it triggers via glFlush() is a waste of resources. So VirtualGL should really be ignoring glFlush() in the case of this app, and in fact, if I hack VirtualGL to do so, the app works fine. My suggestion would be to add an additional environment variable to VirtualGL that, when set to 1, will cause VirtualGL to ignore glFlush() commands and not trigger a readback for those commands. Since it is such a simple fix, it can easily be incorporated into the upcoming 2.3.1 release. On 4/7/12 4:23 AM, Arthur HUILLET wrote: > Hello, > > when using Tecplot with VirtualGL I encounter strange display artifacts (I > can't describe them just now but I'll try to provide a small video showing > them). > > Does anyone have experience running Tecplot with VirtualGL? If so, are there > any particular tricks to making it work? Tecplot support tells me that > they're aware of the issue but are unsure whether it's a bug on their side or > in VirtualGL. > > Thanks ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
