[PATCH 4/5] wined3d: Always use glFinish() for synchronization when cleaning up a GL context.

[Matteo Bruni]

On Wed, Feb 9, 2022 at 7:44 PM Henri Verbeet <hverbeet at gmail.com> wrote:
>
> On Wed, 9 Feb 2022 at 16:50, Matteo Bruni <mbruni at codeweavers.com> wrote:
> > @@ -1377,18 +1377,13 @@ static void wined3d_context_gl_cleanup(struct wined3d_context_gl *context_gl)
> >      {
> >          /* If we're here because we're switching away from a previously
> >           * destroyed context, acquiring a context in order to submit a fence
> > -         * is problematic. (In particular, we'd end up back here again in the
> > -         * process of switching to the newly acquired context.) */
> > -        if (context_gl->c.destroyed)
> > -        {
> > -            gl_info->gl_ops.gl.p_glFinish();
> > -        }
> > -        else
> > -        {
> > -            wined3d_context_gl_submit_command_fence(context_gl);
> > -            wined3d_context_gl_wait_command_fence(context_gl,
> > -                    wined3d_device_gl(context_gl->c.device)->current_fence_id - 1);
> > -        }
> > +         * is problematic. In particular, we'd end up back here again in the
> > +         * process of switching to the newly acquired context.
> > +         *
> > +         * We have to wait for all pending commands to complete and we might
> > +         * not support fences, so we might as well unconditionally
> > +         * glFinish(). */
> > +        gl_info->gl_ops.gl.p_glFinish();
> >
> I suppose this is probably fine in practice, but glFinish() always
> makes me a bit uncomfortable; I'd prefer just checking for the
> availability of fences, like in 5/5. Taking that one step further, if
> fences aren't supported, I don't think there's anything we would need
> to wait for in the first place; we can probably just avoid the
> glFinish() in that case as well.

Good point, I'll give that a try.