[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 #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
surprising).

-- 
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>