<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [i915] Feature request: Add support for fencing for PRIME setups" href="https://bugs.freedesktop.org/show_bug.cgi?id=95472#c9">Comment # 9</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [i915] Feature request: Add support for fencing for PRIME setups" href="https://bugs.freedesktop.org/show_bug.cgi?id=95472">bug 95472</a> from <a class="email" href="mailto:chris@chris-wilson.co.uk" title="Chris Wilson <chris@chris-wilson.co.uk>"> Chris Wilson</a> <pre>Bisecting that lockup would be invaluable to me. DRI2 render offload goes something like: GL client renders to back -> DRI2SwapBuffers -> X/dgpu CopyRegion2, copy back to front + post damage -> DamageEvent -> compositor copies on igfx damaged front onto framebuffer and flips -> DRI2SwapBuffers -> X/igfx flips (DRI3 is a couple of steps simpler, in that the dgpu copy is done by the GL client and only the X/igfx is involved with handling Present) The point at which we require the fence is between the copy by the dgpu inside X and the copy by the igfx inside the compositor. The buffer is passed between dgpu and igfx using a dma-buf, which also carries along the implicit fences. So long as the fencing is correct that should be fine. Q: Is it only the PRIME offload that tears? Does enabling TearFree do anything? (Just trying to ascertain that it is the fence and not the last SwapBuffers that is at fault.) If you want to look at intel-gpu-tools/tests/prime_vgem, tests/prime_busy should test the basic export/import of fences. I'll patch in some debug messages tomorrow to show whether we are seeing fences in i915 execbuf.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>