On Tue, 1 Mar 2011 12:00:12 +0100, Jakob Bornecrantz <wallbra...@gmail.com> wrote: > On Mon, Feb 28, 2011 at 10:11 PM, Ian Romanick <i...@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 <e...@anholt.net> wrote: > >>> On Tue, 22 Feb 2011 11:57:38 -0800, Ian Romanick <i...@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.
pgpj9MhuWG2Ki.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
