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

[Ian Romanick]

-----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.

The reality is that this just moves the implicit lock from MakeCurrent
(which doesn't really exist) out to an explicit lock in the application.
 Since we're talking about a very small group of people of hopefully
elite people, I think we can give them as much rope to shoot themselves
in the foot.

The current error case is an X protocol error.  I have yet to see an app
correctly handle a GLX error that shows up as an X protocol error.  In
reality, we trading an app crashing (due to an unhandled X protocol
error) for an app with unpredictable behavior.  I can't really say which
is worse.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1sD28ACgkQX1gOwKyEAw81NgCaAl/ycTA+2fhrJFEhvf6uqsq/
vUAAnjcsKUXG5/DR181gbtWm9QLQEM+V
=DHbC
-----END PGP SIGNATURE-----