Frank Henigman <fjhenig...@google.com> writes: > On Wed, Jun 12, 2013 at 1:33 PM, Eric Anholt <e...@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).
pgpvZS0k4_U57.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
