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

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Dec 28 21:20:22 UTC 2016


--- Comment #4 from Kenneth Graunke <kenneth at whitecape.org> ---
(In reply to Chad Versace from comment #3)
> +ken +jason
> Helgrind complains about potential read/write races on
> drm_intel_gem_bo::offset64. According to helgrind, the conflict occurs when
> intel_batchbuffer_flush() updates the offset in thread1 and
> brw_update_texture_surfaces() reads the offset during batchbuffer
> construction in thread2.

I think that should be harmless.  offset64 is the presumed location of the
buffer - i.e. our guess where the kernel relocated it to on the last execbuf. 
If we guess correctly, the kernel sees that everything's where we think it is
and skips relocating things.  If we guess wrong, it goes ahead and does
relocations anyway.

At least, that's how I understand it.  It's good to know about this though.

I did notice that it passes with INTEL_DEBUG=sync (which I suppose is not

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/20161228/779696d7/attachment.html>

More information about the intel-3d-bugs mailing list