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

[Jakob Bornecrantz]

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

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

I'll take a defined error over a undefined crash anytime. If its opt
in worst case is that they have to search the GLX spec for all
conditions that raise BadAccess.

Reading the MakeCurrent specs its says it returns False if it failed,
so I assume we get False back and a error, or is this X we are talking
about? If not the application does get instant feedback.

Cheers Jakob.