Summary: | Rendering sometimes halts in waiting for back buffers with dri3 & xwayland | ||
---|---|---|---|
Product: | Mesa | Reporter: | Boyan Ding <stu_dby> |
Component: | GLX | Assignee: | mesa-dev |
Status: | RESOLVED NOTOURBUG | QA Contact: | |
Severity: | normal | ||
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: | A simple program that can effectively trigger the halt on my machine |
Description
Boyan Ding
2014-07-10 02:32:53 UTC
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.