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

[Eric Anholt]

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?

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.

> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130611/d3261f44/attachment.pgp>