<html>
    <head>
      <base href="https://bugs.freedesktop.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - glmark2-es2-wayland shortly freezes on some frames with egl_dri2 backend (Nouveau/GK20A)"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=86690#c7">Comment # 7</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - glmark2-es2-wayland shortly freezes on some frames with egl_dri2 backend (Nouveau/GK20A)"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=86690">bug 86690</a>
              from <span class="vcard"><a class="email" href="mailto:gnurou@gmail.com" title="Alexandre Courbot <gnurou@gmail.com>"> <span class="fn">Alexandre Courbot</span></a>
</span></b>
        <pre>Some more input about this oddity.

We are really waiting for fences here. During the freezes I can see the EGL
client looping in nouveau_fence_wait(), and displaying the fence sequence and
the highest signaled fence by the screen (screen->fence.sequence_ack) shows
that sequence_ack < fence->sequence, indicating the GPU has not signaled this
fence yet.

I am starting to suspect a CPU scheduling issue here. Another very interesting
phenomenon happens if I disable all but 1 CPU core: the issue becomes
immediately visible (even worse than when perf top is running), for all Wayland
EGL clients that set eglSwapInterval to 0. Wayland itself (or any DRM program
for that instance) is still not affected, neither are Wayland clients not
touching eglSwapInterval *until* they exit, at which point nouveau_fence_wait()
will again endlessly loop on a fence. One way to release that fence is to
trigger a draw event in another client. Then the screen's sequence_ack finally
increases and the client goes through and exits. Doing the same in a client
that set eglSwapInterval(0) allows it to draw a few frames, and then it blocks
again.

I suspect that some event in Wayland remains stuck somewhere, which leads to
the EGL client to wait for a fence that Wayland fails to release when expected.
Here is a gdb backtrace of weston-simple-egl when waiting for the fence:

#0  0xb6d9298c in sched_yield ()
#1  0xb6a448ce in nouveau_fence_wait ()
#2  0xb6a45480 in nouveau_screen_fence_finish ()
#3  0xb69a351e in dri_flush ()
#4  0xb6fc399e in dri2_wl_swap_buffers_with_damage ()
#5  0xb6fc0f66 in dri2_swap_buffers_with_damage ()
#6  0xb6fb700c in eglSwapBuffersWithDamageEXT ()
#7  0x0000aa4a in redraw (data=0xbefff9e4, callback=0x0, time=0)
#8  0x0000b254 in main (argc=2, argv=0xbefffc64)

I guess the next step for me is to find how to get some output about Wayland
events as they happen and see which one remains stuck.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>