After the latest xf86-video-intel update in Arch Linux from version 2.99.917+654+ga508b11 to 2.99.917+662+gb617f80, several people, including me, have started experiencing "lag" in certain applications. What happens is not exactly lag, it's that the screen (or maybe just the particular application?) stops updating until triggered by something like mouse movement. I did a bisect, it's commit 46ffdf2 "sna/dri2: Avoid chaining swaps across a mode change" that causes it.
Addendum: It's not the commit I mention in the first comment. I thought it was, because things were working fine for a while with a driver version before that commit, but now I have screen update problems again. As I'm typing this comment, what I'm typing does not appear on the screen until I move the mouse. It seems it won't be easy to bisect this, as it only starts happening after X has been running for a while. No errors appear in the X log or in dmesg.
If moving the cursor helps, first look at changes in the kernel.
Yes, after some experimentation I can conclude it's indeed the kernel, framebuffer compression to be exact. It got turned on by default in the 4.6 kernel. Some people went to the LTS kernel (4.4) to work around the issue, which makes sense, fbc is off there. I'm running 4.7-rc4 right now with i915.enable_fbc=0 on the kernel commandline and that did the trick. Perhaps also interesting, only SNA is affected. Besides going to the LTS kernel, switching to UXA is another workaround people resort to.
Vampl, can you try with latest drm-intel-nighlty which include fix by Chris ( https://cgit.freedesktop.org/drm-intel/commit/drivers/gpu/drm/i915?id=aeecc9696aa04a82d629e7276134bd54b2afc9e2) which should solve this regression but is not yet merged 4.7.x. Moreover, don't disable fbc (remove i915.enable_fbc=0 on your command line)
Didn't fbc get turned off again in 4.7-rc5? I recall seeing that somewhere. Anyway, I compiled drm-intel-nightly, changed the kernel commandline to i915.enable_fbc=1 and switched X acceleration to SNA. I've been running this setup for a few hours now, and the issue has not materialized yet, so it seems it's indeed fixed.
Thanks Vampl, you are right fbc default is off but on BDW this is enabled by default - see following commit 80788a0fbbdfbb125e3fd45a640cddb582160bc7 2016-06-20 drm/i915/fbc: sanitize i915.enable_fbc during FBC init Paulo The DDX driver changes its behavior depending on the value it reads from i915.enable_fbc, so sanitize the value in order to allow it to know what's going on. It uses this in order to choose the defaults for the TearFree option. Before this patch, it would read -1 and always assume that FBC was disabled, so it wouldn't force TearFree. v2: Extract intel_sanitize_fbc_option() (Chris). v3: Rebase. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1460574069-14005-1-git-send-email-paulo.r.zanoni@intel.com
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.