Xwayland now uses dri3 & glamor as means of acceleration, but rendering sometimes halts randomly in waiting for back buffers(See Bug 80963 in wayland). glxgears (and probably programs rendering in single buffer) is affected. Stacktrace when halted is listed below: at glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); #0 0x00007ffff70bd800 in __poll_nocancel () from /usr/lib/libc.so.6 #1 0x00007ffff55fc992 in ?? () from /usr/lib/libxcb.so.1 #2 0x00007ffff55fddc9 in xcb_wait_for_special_event () from /usr/lib/libxcb.so.1 #3 0x00007ffff7bbc495 in dri3_find_back (c=0x605790, priv=0xa346e0) at dri3_glx.c:1103 #4 0x00007ffff7bbc51b in dri3_get_buffer (driDrawable=0x6a48e0, format=4107, buffer_type=dri3_buffer_back, loaderPrivate=0xa346e0) at dri3_glx.c:1127 #5 0x00007ffff7bbc92e in dri3_get_buffers (driDrawable=0x6a48e0, format=4107, stamp=0x6a4910, loaderPrivate=0xa346e0, buffer_mask=1, buffers=0x7fffffffe640) at dri3_glx.c:1274 #6 0x00007ffff3563c10 in intel_update_image_buffers (brw=0x7ffff7fd4040, drawable=0x6a48e0) at brw_context.c:1395 #7 0x00007ffff3563436 in intel_update_renderbuffers (context=0x6a4020, drawable=0x6a48e0) at brw_context.c:1087 #8 0x00007ffff35634cd in intel_prepare_render (brw=0x7ffff7fd4040) at brw_context.c:1108 #9 0x00007ffff3556969 in brw_clear (ctx=0x7ffff7fd4040, mask=18) at brw_clear.c:234 #10 0x00007ffff31b875e in _mesa_Clear (mask=16640) at main/clear.c:226 #11 0x00000000004027fa in draw () at gears.c:183 #12 0x00007ffff76b1ac4 in ?? () from /usr/lib/libglut.so.3 #13 0x00007ffff76b5329 in fgEnumWindows () from /usr/lib/libglut.so.3 #14 0x00007ffff76b207d in glutMainLoopEvent () from /usr/lib/libglut.so.3 #15 0x00007ffff76b28e5 in glutMainLoop () from /usr/lib/libglut.so.3 #16 0x00000000004031af in main (argc=1, argv=0x7fffffffeb78) at gears.c:405
Could you tell which distribution you are using ? My guess it that it is a libxcb bug. Debian packages have the fix (which is http://cgit.freedesktop.org/xcb/libxcb/commit/?id=3b72a2c9d1d656c74c691a45689e1d637f669e3a)
(In reply to comment #1) > Could you tell which distribution you are using ? I'm using Arch Linux, in which almost everything is vanilla. > My guess it that it is a libxcb bug. > Debian packages have the fix (which is > http://cgit.freedesktop.org/xcb/libxcb/commit/ > ?id=3b72a2c9d1d656c74c691a45689e1d637f669e3a) Thanks, I'll give it a try.
Created attachment 102515 [details] A simple program that can effectively trigger the halt on my machine The problem persists with that patch. This is a simple program which I accidentally find can trigger the halt effectively on my machine, and is the same after applying that patch.
(In reply to comment #1) > My guess it that it is a libxcb bug. > Debian packages have the fix (which is > http://cgit.freedesktop.org/xcb/libxcb/commit/ > ?id=3b72a2c9d1d656c74c691a45689e1d637f669e3a) I tried git version of libxcb and xcb-proto today and the problem still remains.
I think it's not about xcb bug. I turned on DebugPresent output and that's what I get when running glxgears: q 1 0x2bf5a30 351258: 00400006 -> 00400002 (crtc (nil)) e 1 ust 5854416007 msc 351258 c 0x2bf5a30 351258: 00400006 -> 00400002 i 00400006 d 1 0x2bf5a30 351258: 00400006 -> 00400002 q 2 0x35e42a0 111514530873345: 00400006 -> 00400002 (crtc (nil)) e 2 ust 5854416646 msc 351258 c 0x35e42a0 351258: 00400006 -> 00400002 i 00400006 d 2 0x35e42a0 111514530873345: 00400006 -> 00400002 q 3 0x35e42a0 111514530873346: 00400006 -> 00400002 (crtc (nil)) e 3 ust 5854417065 msc 351258 c 0x35e42a0 351258: 00400006 -> 00400002 i 00400006 d 3 0x35e42a0 111514530873346: 00400006 -> 00400002 q 4 0x35e42a0 463856467970: 00400006 -> 00400002 (crtc (nil)) (both the output and the animation stop here) That means the event waited for is even not sent.
I tested the program and confirmed I have the same problem with mesa git. However on this branch https://github.com/axeldavy/mesa/tree/submit4, I don't get the bug. This is quite strange. Could test it and say if you have the bug with it too ?
Hum... strangely after testing again, it doesn't work too now with this branch. Perhaps the bug is from Xserver side.
(In reply to comment #7) > Perhaps the bug is from Xserver side. I guess it may be the case. But where is the problem in xserver -- xwayland or glamor or else? If it is not in xwayland, I guess there is possibly a way to reproduce that out of it. But I'm not an expert in that.
For Xwayland, Present uses the Present fallback implementation. If never present_fake_queue_vblank is called with a msc too low (already passed), then perhaps it's going to wait forever. My guess is that for an unknown reason, this function is called with a past msc.
(In reply to comment #9) > If never present_fake_queue_vblank is called with a msc too low (already > passed), then perhaps it's going to wait forever. My guess is that for an > unknown reason, this function is called with a past msc. I can observe the target_msc changes drastically when running glxgears, when traced at present_pixmap. In the apps that works okay, target_msc only increases by one.
I found the following things: 1. When things are right the window_msc argument of present_pixmap is always a small number (often 1 or sometimes 2), but when things starts to go wrong, it can be very big. 2. When things go wrong (window_msc is very big), present_pixmap is directly originated in dri3_swap_buffers in dri3_glx.c in mesa, which is called by glXSwapBuffers like the following: (*pdraw->psc->driScreen->swapBuffers)(pdraw, 0, 0, 0, flush) ^ 3. target_msc (will be window_msc in present_pixmap) in dri3_swap_buffers is originally 0 (note the mark on the previous line). So it is re-calculated according to the following expression: target_msc = priv->msc + priv->swap_interval * (priv->send_sbc - priv->recv_sbc); and priv->msc is guilty of the big value (Seems that it should be 0 or 1 normally). How can priv->msc change?
Have you rebuild mesa and xwayland after installing libxcb git ? I think I had accidentally scratched my libxcb installation by the arch package, but installing the libxcb git doesn't seem to be sufficient : I rebuilt Mesa and Xwayland, and can't reproduce the bug anymore.
(In reply to comment #12) > Have you rebuild mesa and xwayland after installing libxcb git ? Oh, I didn't. Things now works like a charm after the rebuild. The ABI has changed so rebuilding is necessary.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.