Summary: | Lag on terminal with compositing after 1f6dfc9 | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Andreas Reis <andreas.reis> | ||||||
Component: | Driver/intel | Assignee: | Chris Wilson <chris> | ||||||
Status: | RESOLVED DUPLICATE | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||
Severity: | normal | ||||||||
Priority: | medium | CC: | jdelvare | ||||||
Version: | git | ||||||||
Hardware: | x86-64 (AMD64) | ||||||||
OS: | Linux (All) | ||||||||
Whiteboard: | |||||||||
i915 platform: | i915 features: | ||||||||
Attachments: |
|
Description
Andreas Reis
2016-08-11 14:51:04 UTC
To isolate the changes: diff --git a/src/sna/sna_accel.c b/src/sna/sna_accel.c index 05007bc..4726067 100644 --- a/src/sna/sna_accel.c +++ b/src/sna/sna_accel.c @@ -17385,7 +17385,7 @@ sna_flush_callback(CallbackListPtr *list, pointer user_data, pointer call_data) { struct sna *sna = user_data; - if (!sna->needs_dri_flush) + if (!sna->needs_dri_flush && 0) return; sna_accel_flush(sna); should be equivalent to reverting the dri portion. That's worth double checking to see if the dri or shm halves. I indeed don't see the lag with the && 0. My "test" is just messing with the terminal though (compiling stuff while switching between full-terminal mutt & tig on tmux). Created attachment 125724 [details]
screenshot
Managed to get a screenshot after all. This is from repeated quick switching between two tmux windows, one running a compilation, the other with tig.
Tracking through this the issue really appears to be that in dri2 there is a synchronisation point in comptom with X when it acquires the textures for composition, but in dri3 there is no equivalent X11 request. Instead it queries the XserverRegion corresponding to the damage (rather than tracking the latest damage through DamageNotifyEvents) which means that the rendering in the compositor lags behind the last flush in X when sending the damage event. As I understand it, it is lacking an appropriate glXWaitX() like: diff --git a/src/opengl.c b/src/opengl.c index 5a98f4e..c6cea55 100644 --- a/src/opengl.c +++ b/src/opengl.c @@ -1050,6 +1050,8 @@ glx_set_clip(session_t *ps, XserverRegion reg, const reg_data_t *pcache_reg) { rects = &rect_blank; } + glXWaitX(); + assert(nrects); if (1 == nrects) { glEnable(GL_SCISSOR_TEST); Unfortunately, even after applying that patch to compton the lag is still there. Does seem like it could have gotten less bad, but it's still very visible. Yup, in mesa/dri3 there is no synchronisation yet.... It needs something like diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c index 2f09431..3315828 100644 --- a/src/loader/loader_dri3_helper.c +++ b/src/loader/loader_dri3_helper.c @@ -554,8 +554,17 @@ loader_dri3_wait_x(struct loader_dri3_drawable *draw) struct loader_dri3_buffer *front; __DRIcontext *dri_context; - if (draw == NULL || !draw->have_fake_front) + if (draw == NULL) + return; + + if (!draw->have_fake_front) { + struct loader_dri3_buffer *back = dri3_back_buffer(draw); + + dri3_fence_reset(draw->conn, back); + dri3_fence_trigger(draw->conn, back); + dri3_fence_await(draw->conn, back); return; + } front = dri3_fake_front_buffer(draw); dri_context = draw->vtable->get_dri_context(draw); to flesh out glXWaitX(). applied to mesa and rebooted – still getting the lag Hmm. That *should* do an explicit flush of X rendering before reading from those surfaces. We can't use xtrace because of DRI3 (so we can't confirm if comptom/mesa is signaling the flush) and in the ddx it is hard to identify who calls the sync-flush as it is called very regularly. So printf debugging! First can you please confirm we are hitting the new code in mesa? Created attachment 125937 [details] [review] "fprintf + dri3_fence_*" patch Sorry for the delay, I was busy. Now I * applied the attached "fprintf + dri3_fence_*" patch to loader_dri3_helper.c * recompiled mesa as usual (ie, no added debug settings, as I didn't read that anywhere) * added the following to my .zprofile (which afterwards calls startx): export LIBGL_DEBUG=verbose export MESA_DEBUG=1 export MESA_LOG_FILE=/tmp/mesa.log * also recompiled compton with the glXWaitX() for good measure * and restarted. Nothing. The MESA_LOG_FILE isn't even created. Did I miss a step? GCC is at today's 20160821 now, xf86-video-intel at 12c14deb (without the && 0). glx-no-rebind-pixmap = true; seems to be the culprit as it disables correct behaviour. Does appear to improve things, but unless my eyes deceive me, I'm still seeing some lag and contents of two tmux windows overlap while switching between. Still using the glXWaitX'ed compton and patched mesa, current git. *** This bug has been marked as a duplicate of bug 97914 *** Andreas, for completeness, on what hardware do you get this bug? Two Haswells. Actually I'm no longer getting it. Have been running mesa-git with Chris's "DRI2/DRI3 sync" mesa patch from the bug report of which this one's been marked as duplicate. compton.conf is just backend = "glx"; vsync = "opengl-swc"; |
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.