<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#c4">Comment # 4</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>(In reply to Chad Versace from <a href="show_bug.cgi?id=99209#c3">comment #3</a>) > +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).</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>