[Mesa-dev] [PATCH] mesa: per-texture locking
airlied at gmail.com
Wed Jun 12 16:08:23 PDT 2013
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
>> texture effectively locked them all. With my change that's no longer true
>> 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
>> 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
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.
More information about the mesa-dev