Hmm, I did not know that. Can we do
((GLuint64)1) << 62
Also, I am a little confused about your comment that the patch doesn't preserve the low bits. My aim was to keep 0xffff0000 in the low 32 bits - doesn't "- 0xffff" achieve that goal?
Thanks for your feedback.
Robert On Sat, Aug 12, 2017 at 05:28 Henri Verbeet hverbeet@gmail.com wrote:
On 12 August 2017 at 11:06, nneonneo@gmail.com wrote:
/* Apple seems to be into arbitrary limits, and timeouts larger
than
* 0xfffffffffffffbff immediately return GL_TIMEOUT_EXPIRED. We
don't
* really care and can live with waiting a few μs less. (OS X
10.7.4). */
/* Timeouts near 0xffffffffffffffff may immediately return
GL_TIMEOUT_EXPIRED,
* possibly because macOS internally adds some slop to the
timer. To avoid this,
* we use a large number that isn't near the point of overflow
(macOS 10.12.5).
*/ GLenum gl_ret = GL_EXTCALL(glClientWaitSync(fence->object.sync,
GL_SYNC_FLUSH_COMMANDS_BIT, ~(GLuint64)0xffff));
GL_SYNC_FLUSH_COMMANDS_BIT, (GLuint64)((1ULL << 62ULL)
- 0xffff)));
Adjusting the workaround is probably fine, but ULL literals are not portable. Does something along the lines of "~(GLuint64)0 >> 1" work as well? I don't think we care about the low bits, but note that the patch as it is doesn't actually preserve them.