[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 #15 from Jason Ekstrand <jason at jlekstrand.net> ---
(In reply to Kenneth Graunke from comment #11)
> Jason was thinking we use I915_EXEC_NO_RELOC, but we don't.  I don't think
> that's a problem.  An easy way to sanity check that would be to remove
> offset64 from Mesa's relocations (effectively always programming an assumed
> offset of 0).

I think Ken is right and it's not as dire as I'd feared.  Relocations should be
safe so long as we continue to not use NO_RELOC.

(In reply to Kenneth Graunke from comment #14)
> if you want to burn some cycles looking into making Mesa's texture locking
> less incompetent, that would probably be worthwhile.  I'm also a bit
> concerned that I had to make the texture lock a recursive mutex a while
> back, when Kristian implemented meta fast clears...it may be that meta
> altering texturing state in this case isn't really valid - similar to our
> old recursive-meta hell.
> 
> It may be that switching things to BLORP is more of an actual solution than
> the paper-over we feared it might be.

Short-term, yes, that may fix this bug.  It should be easy enough to grab
Topi's patches, apply them, and see if that fixes it.  Long-term, we still have
a lot of meta paths and getting rid of them will take time.  Not sure if it's
better to get rid of them or to fix them.

-- 
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/20170111/11b5f8c7/attachment.html>