<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - [EGL, i965] dEQP-EGL.functional.sharing.gles2.multithread.simple_egl_server_sync.textures.copyteximage2d_texsubimage2d_render" href="https://bugs.freedesktop.org/show_bug.cgi?id=99209#c12">Comment # 12</a> on <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - [EGL, i965] dEQP-EGL.functional.sharing.gles2.multithread.simple_egl_server_sync.textures.copyteximage2d_texsubimage2d_render" href="https://bugs.freedesktop.org/show_bug.cgi?id=99209">bug 99209</a> from <a class="email" href="mailto:kenneth@whitecape.org" title="Kenneth Graunke <kenneth@whitecape.org>"> Kenneth Graunke</a> <pre>I think Tapani is on to something here. If the texture is busy and we can't immediately write to it, _mesa_meta_pbo_TexSubImage decides to create a PBO, copy the user supplied data into the PBO, then essentially blit (texture/render) from the PBO to the destination texture. It does this to try and avoid stalling. So...it should totally be legal to do: bool tex_busy = true; namely, always take this "create a PBO and blit" path. It should always be viable, and this should remove some unpredictability. However, doing so uncovers a bit problem: deqp-egl: main/texobj.c:2030: _mesa_unlock_context_textures: Assertion `ctx->Shared->TextureStateStamp == ctx->TextureStateTimestamp' failed. I think the Meta path is exposing Mesa's bogus texture locking.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>