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

[Eric Anholt]

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 huge digression about potential optimizations that I don't see
this patch affecting]

> As far as I can tell, allowing multiple threads access to a single
> context makes it impossible to eliminate the reader lock.  This also
> means that no other vendor will ever implement this functionality.

[...]

> I thought we also decided that the bulk of the MakeCurrent overhead in
> cairo-gl was due to the implicit flush in the old context when making a
> new context current.  Can't we just fix that instead?  Though even that
> is tricky to accurately specify and implement in the presence of
> multiple contexts with shared objects.  At the very least we'd need to
> make it clear that there's a lot of potentially undefined behavior.  For
> example, even in a single threaded case changes to object X in context A
> may not be visible in context B across a MakeCurrent from A to B even if
> the object is rebound in B.

I'm going to quote the spec proposal again, since from your response it
seems you skipped it:

 +    thread starts working on that object is difficult.  For them,
 +    using the same context across multiple threads and protecting its
 +    usage with a mutex is both higher performance and easier to
 +    implement.  This extension gives those applications that option by
 +    relaxing the context binding requirements.

[...]

 +    is not an option, and synchronizing of GL's access to the GL
 +    context between multiple threads is left to the application to do
 +    across GL calls.  However, it would be unfortunate for a library

[...]

We (the user) require serialized rendering.  Thus having our rendering
stream going through a single context, with the *caller* of the GL API
using pthread mutexes around its usage of the GL API so that it's safe,
even in the face of all your optimizations you talked about.  If the
caller screws up and doesn't lock things, that's the same in my book as
the caller screwing up and handing a bogus pointer to glBufferData.  If
we want to add wording to that extent, we can.

> I thought we also decided that the bulk of the MakeCurrent overhead in
> cairo-gl was due to the implicit flush in the old context when making a
> new context current.  Can't we just fix that instead?  Though even that
> is tricky to accurately specify and implement in the presence of
> multiple contexts with shared objects.  At the very least we'd need to
> make it clear that there's a lot of potentially undefined behavior.  For
> example, even in a single threaded case changes to object X in context A
> may not be visible in context B across a MakeCurrent from A to B even if
> the object is rebound in B.

Yes, the CPU cost is there.  If we were to do MCMT and try to not flush
after every call, then when I get a cairo call in thread A and then
thread B, thread B would need a way to go reach over into thread A and
make him call glFlush.  Proposals of how to do that are welcome, it
should be fun.

> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.cairographics.org/archives/cairo/attachments/20110222/5abe421b/attachment.pgp>