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

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Henri Verbeet
On 12 August 2017 at 11:06,  <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [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 <[hidden email]> wrote:
On 12 August 2017 at 11:06,  <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Henri Verbeet
On 12 August 2017 at 16:29, Robert Xiao <[hidden email]> wrote:
> Hmm, I did not know that. Can we do
>
> ((GLuint64)1) << 62
>
Yeah, that should work. Not sure there's a reason to prefer it over
"~(GLuint64)0 >> 1" though.

> 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?
>
No, that gets you 0x3fffffffffff0001. But as I said, I don't think it
matters. ~0xffff was chosen because it was an easy to write value
smaller than 0xfffffffffffffbff, not because it was otherwise special.


Loading...