Skip to content

mesa: (correctly) flush more in _mesa_make_current

Adam Jackson requested to merge ajax/mesa:mesa-fix-make-current into main

There's two && branches being removed here. They both require more of the context before a flush will be emitted, they both seem to be optimizations to avoid excess flushing, and they are both wrong. The first one requires that the context have a window-system drawable bound to the default framebuffer. I can find no justification for restricting flushes to contexts like this, and GL 3.0 (etc) let you make a context current without any drawable bound. The side effect required by MakeCurrent is a flush, not a flush only if another process might be able to see it.

The second one requires that we're not just re-binding the context but changing from one to another. If I had to guess, this conditional was inferred from the glXMakeCurrent manual page:

Pending commands to the previous context, if any, are flushed before it is released.

You could read this as not requiring a flush, because if the old and new contexts are the same you're arguably not switching context, thus there is no "previous" context to flush. But the GLX spec (1.4 § 3.3.7 "Rendering Contexts") says something sterner:

If the calling thread already has a current rendering context, then that context is flushed and marked as no longer current. ctx is made the current context for the calling thread.

Nothing ambiguous there: if a context is current, it gets flushed. The EGL spec (1.5 § 3.7.3 "Binding Contexts and Drawables") inherits similar language, and GL_KHR_context_flush_control only adds the ability for the context to opt out of the implicit flush entirely.

Fixes: 60ec95fa mesa: Add support for the GL_KHR_context_flush_control extension


The first patch is to preemptively fix a crash that the second patch would trigger. I don't love it, but it's fine. I could be convinced that each point above should be its own patch.

cc a bunch of people who've been in the async-flush threads recently @anholt @mareko @zmike @pepp @daenzer @robclark

Merge request reports