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

[Dave Airlie]

On Thu, Jun 13, 2013 at 3:33 AM, Eric Anholt <eric at anholt.net> wrote:
> Frank Henigman <fjhenigman at google.com> writes:
>
>> 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.
>
> That's an example of my concern.
>
>> 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?
>
> Basic ABBA locking problems.  Someone does a copyteximage from texture A
> to fbo-wrapped texture B, at the same time someone does copytexsubimage
> From texture B to fbo-wrapped texture A.
>
> The timeline for ABBA failure is:
>
> thread 1:                  thread 2:
> lock texture A
>                            lock texture B
> block locking texture B
>                            block locking texture A
>

I suspect you'd need a reservation type scheme like the one Maarten is
writing for
the kernel, and based on the one TTM uses.

Where you get a list of objects you want to lock and back off all locks when
you hit a contended point.

Dave.