[Mesa-dev] [Bug 86690] glmark2-es2-wayland shortly freezes on some frames with egl_dri2 backend (Nouveau/GK20A)

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Nov 25 04:45:38 PST 2014


--- Comment #2 from Pekka Paalanen <ppaalanen at gmail.com> ---
(In reply to Alexandre Courbot from comment #1)
> Created attachment 109990 [details]
> 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.

You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20141125/857eae98/attachment.html>

More information about the mesa-dev mailing list