I think glFenceSync+glFlush in one context and glWaitSync (server-side synchronization) in the other context would be the best solution. It shouldn't block the CPU, but it should set the right ordering of commands. glFinish seems to be overkill.
Marek On Mon, Nov 19, 2012 at 10:27 PM, Eric Anholt <e...@anholt.net> wrote: > Paul Berry <stereotype...@gmail.com> writes: > >> Currently, in Mesa with the i965 driver, calling glFlush() forces all >> pending drawing operations to be sent to the kernel; this ensures that >> any subsequent drawing operations will be performed after those >> pending drawing operations, even if they come from other contexts. >> The glx-multithread test was relying on this behaviour, however, the >> GL and GLX specs do not garantee this. >> >> This patch modifies the glx-multithread test to use glFinish() instead >> of glFlush(). > > I'll have to keep this in mind if I ever write some of the other glx > tests I've thought about. > > Reviewed-by: Eric Anholt <e...@anholt.net> > > _______________________________________________ > Piglit mailing list > Piglit@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/piglit > _______________________________________________ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
