[Mesa-dev] [PATCH] mesa: per-texture locking

[Frank Henigman]

On Tue, Jun 11, 2013 at 1:10 PM, Eric Anholt <eric at anholt.net> wrote:

> Frank Henigman <fjhenigman at google.com> writes:
>
> > Replace the one texture lock with a lock per texture.  This allows
> > uploading textures from one thread concurrently with drawing in another
> > thread.  _mesa_lock_context_textures() was used to check for texture
> > updates from other contexts and also to acquire the texture lock.
> > It's been replaced with _mesa_check_context_textures() which only does
> > the checking.  Code sections that were between
> > _mesa_lock_context_textures() and _mesa_unlock_context_textures()
> > have been updated to lock individual textures as needed.
>
> When someone's doing something like glCopyTexSubImage() from an FBO
> backed by a texture to another texture, how is the locking supposed to
> work?  How about copies from one texture to the same texture?
>

Right now glCopyTexSubImage locks the destination texture before copying
to it, but doesn't lock the source texture.  This was safe because locking
any
texture effectively locked them all.  With my change that's no longer true
so
now we're copying from an unlocked texture.  Is that your concern?
So we just need to have it lock the source texture too?
We'll have to check for source == destination so we don't try to lock twice.

I'm pretty sure that our current locking doesn't cover nearly as much as
> it needs to if one wants to make thread-per-context shareCtx support
> actually work, so I'm really concerned that this change may make the
> locking unfixable.
>

I agree there probably are problems with locking currently, and there seems
to be zero coverage for context sharing in piglit.  But I don't understand
how
my change makes anything unfixable.  Can you elaborate?

> No piglit regressions on pineview with intel driver.
> > Passes new piglit test glx-multithread-texture.
>
> This test doesn't do any concurrent access of textures as far as I can
> see, so I don't think it really exercises this patch.
>

The idea behind the test was to mimic an actual use case and show
that my patch increases concurrency.  I had thought to actually measure
concurrency in the test (maybe by timing how long the threads wait)
but realized this would fail on single core machines so I left that out,
though I can still tell the patch helps because the test completes
significantly
faster with it.

There's plenty of room for more shared context tests, especially as there
weren't any.  I'd like to start by considering likely uses.  I'm thinking
any
use of shared contexts will probably include some synchronization between
the users.  If you think there's value in a test of concurrent access to a
texture I'll write one (including your glCopyTexSubImage scenarios).
I'm interested in any suggestions as to the most useful tests to have at
this point.   Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130612/36733233/attachment.html>