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

Eric Anholt eric at anholt.net
Fri Jun 14 09:43:22 PDT 2013


Frank Henigman <fjhenigman at google.com> writes:

> On Wed, Jun 12, 2013 at 1:33 PM, Eric Anholt <eric at anholt.net> wrote:
>> glCopyTexSubImage was just an example of "reads from texture and writes
>> to texture, thanks to FBOs" -- you've also got the normal drawing path,
>> glCopyPixels, glDrawPixels, glBitmap, glBlitFramebuffer.  If zero-copy
>> PBOs are reintroduced, then glReadPixels() and glGetTexImage() are
>> concerns.
>>
>
> There seem to be two categories here: operations on one texture and
> and operations on multiple textures.  For the former, I don't think my patch
> does any harm.  There may be places where locking is lacking but those
> have been there all along and should be fixable by adding locking.
> In the second category there's work to do for glCopyTexSubImage() and the
> other functions you mention, but they seem fixable, even for insane usage.
> As for "the normal drawing path" I don't think I've harmed that either.
> It doesn't look like any driver holds the lock during rendering (except the
> intel 915 driver does "lock all textures" in intelRunPipeline() for reasons
> I don't understand) therefore they don't become less safe in the way
> glCopyTexSubImage() did.

Just because drivers aren't doing locking doesn't mean they don't need
it.  For example, right now TexImage is done by freeing the old buffer,
then some time later making a new buffer.  When you're drawing from that
texture in another thread, you should receieve either old or new
(depending on when you bound, or maybe new even when you bound with
old), but instead if you draw at the wrong time you just segfault
because the image storage was gone when it absolutely shouldn't have
been.

(And just dropping the FreeTextureImageBuffer isn't enough -- if you
draw with old with new's size or the other way around, you may scribble
over other GPU memory)

I don't want to see locking pushdown when we know our current global
locking is thoroughly broken, and the locking pushdown would make fixing
things more difficult (ABBA problems).
-------------- 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/20130614/25b5579e/attachment.pgp>


More information about the mesa-dev mailing list