<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <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#c2">Comment # 2</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 <a class="email" href="mailto:ppaalanen@gmail.com" title="Pekka Paalanen <ppaalanen@gmail.com>"> Pekka Paalanen</a> <pre>(In reply to Alexandre Courbot from <a href="show_bug.cgi?id=86690#c1">comment #1</a>) > Created <a href="attachment.cgi?id=109990" name="attach_109990" title="Trace when running glmark2 with WAYLAND_DEBUG=client">attachment 109990</a> <a href="attachment.cgi?id=109990&action=edit" title="Trace when running glmark2 with WAYLAND_DEBUG=client">[details]</a> > Trace when running glmark2 with WAYLAND_DEBUG=client > > Attached the trace suggested by Pekka. The stuttering is visible almost > immediatly after the bench started, and occured regularly until the end of > the trace. Ok, here's a piece of what I detected as delays > 50ms in the protocol dump (timestamp, skip in ms): 2007458 55 2007628 56 2008779 62 2008926 142 2009104 128 2009638 529 2009733 84 2012659 105 2012769 62 2012838 64 It looks quite random in both occurrence and length. I checked the first six, and the delay always happens between damage and commit requests. Due to how libwayland-client prints these, these timestamp are when Mesa calls the functions wl_surface_damage and wl_surface_commit. In src/egl/drivers/dri2/platform_wayland.c (egl_dri2), in dri2_wl_swap_buffers_with_damage() you see these function calls. The things between them are flush and invalidate. One of these probably causes the stall. If we look at egl_gallium in src/gallium/state_trackers/egl/wayland/native_wayland.c, well, the code is different. Swapbuffers and present seem to be two different hooks. I'm not familiar with this code to say what the actual difference is. Maybe egl_dri2 allows queueing many frames' worth of drawing to the GPU and at some point the driver simply has to wait for it all to drain? And egl_gallium does something slightly different? Oh right, you said egl_gallium didn't respect swapinterval=0 but stayed vsynced. That explains why the drawing never accumulates. Looks like wayland_surface_swap_buffers() always waits for the frame callback, which causes exactly the throttling to vsync rate. I believe this would be a case of queueing too much GPU work and eventually having to wait for it to drain. I'm not sure how or where you would start fixing it. Buffer re-use could also be a factor. I am fairly sure this is not a Weston bug. It seems to swapping between the two wl_buffers just fine.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>