[PATCH] wined3d: Reduce timeout value to avoid GL_TIMEOUT_EXPIRED on macOS

[Robert Xiao]

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 at gmail.com> wrote:

> On 12 August 2017 at 11:06,  <nneonneo at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20170812/2c25d024/attachment.html>