Bug 96591 - [4.6 regression] FBC doesn't notice writes to scanout
Summary: [4.6 regression] FBC doesn't notice writes to scanout
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Paulo Zanoni
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-06-19 12:33 UTC by Uros Vampl
Modified: 2017-07-24 22:41 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Uros Vampl 2016-06-19 12:33:44 UTC
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.
Comment 1 Uros Vampl 2016-06-19 12:54:11 UTC
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.
Comment 2 Chris Wilson 2016-06-20 08:03:55 UTC
If moving the cursor helps, first look at changes in the kernel.
Comment 3 Uros Vampl 2016-06-25 10:29:46 UTC
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.
Comment 4 yann 2016-07-11 15:40:26 UTC
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)
Comment 5 Uros Vampl 2016-07-12 14:58:58 UTC
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.
Comment 6 yann 2016-07-13 12:27:10 UTC
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.