The only app I know about that exhibited pathological glFlush() behavior
was Pro/ENGINEER 2.x. That behavior (which we lovingly referred to as
the "10000 flushes bug") was what prompted us ("us" being Sun
Microsystems at the time) to make the spoiling behavior different for
glFlush().
I don't think this patch will cause any actual problems-- in the 10
years I've been doing this, this is only the second app I've run across
that requires VGL_SYNC-- so I've checked it in. However, I do hasten to
point out that, technically, it is not correct to expect any kind of
synchronization with glFlush(). glFlush() is, by definition, an
asynchronous call. It flushes the OpenGL command buffer, "causing all
issued commands to be executed as quickly as they are accepted by the
actual rendering engine. Though this execution may not be completed in
any particular time period, it does complete in finite time." The
execution of the prior rendering commands is not guaranteed to finish
before glFlush() returns, and Cadence is completely wrong to rely on
that call as a means of 2D/3D synchronization. They should be using
glXWaitGL()/glXWaitX() instead.
On 8/25/14 1:39 PM, Nathan Kidd wrote:
> To guarantee correctness with applications that do
> 2D-over-3D drawing we must always sync the 3D bits
> within the X stream.
>
> Example of what happened previously, with Cadence Allegro:
>
> 1. Allegro draws to front buffer with GL
> 2. Allegro does glFlush
> 3. VGL adds frame to queue in separate thread
> 4. Allegro does 2D XOR drawing to window
> 5. VGL queue frame arrives, overwrites XOR drawing
> 6. Allegro "erases" 2D XOR drawing, but actually ends up
> making it visible.
>
> Sometimes 5) could come before 4), and drawing was OK,
> but mostly it looses that race.
>
> Possible side-effect:
>
> Theoretical application that does excessive glFlush'ing and
> requires VGL_SYNC=1 for, e.g. glXSwapBuffers but not for glFlush
> will become unusably slow. If such an application is found
> then an option could be added to not sync on glFlush.
>
> -Nathan
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds. Stuff that matters.
> http://tv.slashdot.org/
>
>
>
> _______________________________________________
> VirtualGL-Devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
>
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
VirtualGL-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
