Frank Henigman <fjhenig...@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.
pgpTZzXHs7N70.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
