[Bug 99209] [EGL, i965] dEQP-EGL.functional.sharing.gles2.multithread.simple_egl_server_sync.textures.copyteximage2d_texsubimage2d_render

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99209

--- Comment #12 from Kenneth Graunke <kenneth at whitecape.org> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20170110/60bb508f/attachment.html>