[Mesa-dev] [PATCH 1/4] mesa: Add new MESA_multithread_makecurrent extension.

[Eric Anholt]

On Tue, 1 Mar 2011 12:00:12 +0100, Jakob Bornecrantz <wallbraker at gmail.com> wrote:
> On Mon, Feb 28, 2011 at 10:11 PM, Ian Romanick <idr at freedesktop.org> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 02/26/2011 03:18 PM, Jakob Bornecrantz wrote:
> >> On Tue, Feb 22, 2011 at 10:08 PM, Eric Anholt <eric at anholt.net> wrote:
> >>> On Tue, 22 Feb 2011 11:57:38 -0800, Ian Romanick <idr at freedesktop.org> wrote:
> >>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>> Hash: SHA1
> >>>>
> >>>> On 02/21/2011 02:41 PM, Eric Anholt wrote:
> >>>>> This extension allows a client to bind one context in multiple threads
> >>>>> simultaneously.  It is then up to the client to manage synchronization of
> >>>>> access to the GL, just as normal multithreaded GL from multiple contexts
> >>>>> requires synchronization management to shared objects.
> >>
> >> [snip]
> >>
> >>>> We may need to make the new behavior opt-in per-context anyway.  This
> >>>> changes some very subtle and touchy GL behaviors, so some of these
> >>>> changes may have unforeseen affects on existing apps.  Changing these
> >>>> things always makes me nervous.  Over the years we've all independently
> >>>> discovered that MakeCurrent and SwapBuffers are like Koch snowflakes...
> >>>> there are *only* corner cases.
> >>>
> >>> GL has in the past changed things that were errors to not be errors to
> >>> extend functionality and make the GL more useful -- see, for example,
> >>> the deltas between GL_EXT_framebuffer_object to
> >>> GL_ARB_framebuffer_object, which didn't first introduce a
> >>> GL_DONT_THROW_ERRORS_FOR_LUMINANCE_FBOS knob.  I don't see why we should
> >>> make the API even harder to access just to preserve an error return.
> >>
> >> The difference is race conditions galore with no defined behavior vs
> >> well defined behavior with just returning a error code. This needs to
> >> be opt in.
> >
> > Eric and I had a long discussion about this last week, and he managed to
> > convince me that it should be safe.  One big data point, of which I was
> > unaware, is that this is the behavior of AGL.  This being the behavior
> > since OS X shipped is strong (though circumstantial) evidence in favor
> > of its safety.
> 
> Was that a change they made when AGL was already widely used API or is
> it something that has been there from the beginning? What does GLX do
> on MacOSX? My problem is not the extension itself but the fact its not
> opt in. Multithreaded race problems are extremely hard to debug, the
> result would that any crash or corruption bug get we would have to ask
> "is this a multithreaded application?".

I don't know the history of AGL.  When I got started on this extension,
I reviewed what other window systems specs were at the time, and noticed
that AGL didn't have the same text.  WGL doesn't have a spec, so I don't
know what it does.

Do you think that there exists a single multithreaded application which
currently uses the X error generated by the old behavior of
glXMakeCurrent() to implement a locking primitive?  I think that is very
unlikely.  As such, I believe that the risk only exists for people
writing new multithreaded applications.  This offers a new, easier
option for going about it using the same multithreaded programming
methods they normally use (pthread mutexes), instead of the
multicontext-and-glFlush() mechanism that existed before, which in my
googling during writing this showed up as something that was quite
painful for app developers.

Also, you should be asking "is this a multithreaded application" anyway
if you think that multithreaded applications are a risk when you get bug
reports.  Given the lack of testing of our GL core under threading (how
many tests do we have in piglit of multithreading with textures, for
example?  Oh, none?), multithreaded applications are likely to find all
sorts of nasty corners in our stack.  I certainly did while trying to
implement and test the extension and spending my time fixing
non-extension-related context handling bugs instead.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110301/5e974b23/attachment.pgp>