glClientWaitSync(fence, GL_SYNC_FLUSH_COMMANDS_BIT, GL_TIMEOUT_IGNORED) often returns GL_TIMEOUT_EXPIRED, even though GL_TIMEOUT_IGNORED is a huge integer (18446744073709551615 on Intel Sandybridge with Mesa). The third argument to glClientWaitSync should represent the number of nanoseconds the implementation waits for the signal from fence before giving up and returning TIMEOUT_EXPIRED. This test (http://cgit.freedesktop.org/~ldeks/piglit/commit/?h=adsa-buffer-objects&id=b473b248dc1366c536876752eefc3dbc844c1657), adapted from bufferstorage-persistent, demonstrates that glClientWaitSync(fence, GL_SYNC_FLUSH_COMMANDS_BIT, GL_TIMEOUT_IGNORED) must be called multiple times before the signal is actually recorded and either GL_CONDITION_SATISFIED or GL_ALREADY_SIGNALED is returned.
I think this is the same issues as with bug #89219
please try again, should have been fixed by: ----------------------------------------------- commit 10c82c6c5fc415d323a5e9c6acdc6a4c85d6b712 Author: Kristian Høgsberg <krh@bitplanet.net> Date: Mon Mar 2 16:19:52 2015 -0800 i965: Fix uint64_t overflow in intel_client_wait_sync() DRM_IOCTL_I915_GEM_WAIT takes an int64_t for the timeout value but GL_ARB_sync takes an uint64_t. Further, the ioctl used to wait indefinitely when passed a negative timeout, but it's been broken and now returns immediately in that case. Thus, if an application passes UINT64_MAX to wait forever, we overflow to -1LL and return immediately. Work around this mess by clamping the wait timeout to INT64_MAX. Signed-off-by: Kristian Høgsberg <krh@bitplanet.net> Reviewed-by: Chad Versace <chad.versace@intel.com>
That fixes it for my piglit/tests/spec/arb_sync-ClientWaitSync-timeout test on IVB.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.