Often times my screen, gets corrupted when the screen is repainting. This is most visible when viewing fullscreen videos, but is also visible when other things are redrawing on the screen. Usually simple mouse movements (without hovering any graphic that repaints) slowly clears the corrupted screen areas (the mouse cursor doesn't really need to overlap the corrupted areas). Since this is hard to explain with words, I made a video of the issue: https://www.youtube.com/watch?v=0HVXcBKpR9U I manually bisected the issue and the commit "74c1e45ed5797eca5dec6dcea8f6f734d23d0f89" appears to be the first one where I can reproduce the problem. I have been using the previous commit and rebooted several times without issue. I have the "TearFree" option enabled in a xorg.conf.d file. I am using KDE5, linux kernel 4.2.3 (Arch Linux). KWin compositor (OpenGL) is active when this happens. Disabling it and re-enabling it appears to fix the issue until the next reboot (didn't test this long enough to be sure the issue doesn't reappear after some time).
Just as important is to please attach your xorg.log. The video is marked as private.
I have updated the video privacy setting, you should now be able to watch it. Sorry about that. I will send the Xorg log as soon as I get home.
That's cacheline dirt. I suspect it from mesa rendering into the buffer overriding the PTE settings that say it must be rendered uncached. There are also a couple of kernel bugs where the GPU writes are not being flushed before the pageflip. For mesa try: diff --git a/src/mesa/drivers/dri/i965/brw_defines.h b/src/mesa/drivers/dri/i965/brw_defines.h index 393f17a..164d54b 100644 --- a/src/mesa/drivers/dri/i965/brw_defines.h +++ b/src/mesa/drivers/dri/i965/brw_defines.h @@ -2709,13 +2709,13 @@ enum brw_wm_barycentric_interp_mode { * On Ivybridge, the PTEs do have a cache-in-L3 bit, so setting MOCS to 0 * may still respect that. */ -#define GEN7_MOCS_L3 1 +#define GEN7_MOCS_L3 0 /* Ivybridge only: cache in LLC. * Specifying zero here means to use the PTE values set by the kernel; * non-zero overrides the PTE values. */ -#define IVB_MOCS_LLC (1 << 1) +#define IVB_MOCS_LLC 0 /* Baytrail only: snoop in CPU cache */ #define BYT_MOCS_SNOOP (1 << 1) For the kernel you need: diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 107c6c0519fd..42d91d6adf9b 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -11233,6 +11233,12 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc, work->gtt_offset = intel_plane_obj_offset(to_intel_plane(primary), obj) + intel_crtc->dspaddr_offset; + if (obj->last_write_req) { + ret = i915_gem_check_olr(obj->last_write_req); + if (ret) + goto cleanup_unpin; + } + if (mmio_flip) { ret = intel_queue_mmio_flip(dev, crtc, fb, obj, ring, page_flip_flags); @@ -11242,12 +11248,6 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc, i915_gem_request_assign(&work->flip_queued_req, obj->last_write_req); } else { - if (obj->last_write_req) { - ret = i915_gem_check_olr(obj->last_write_req); - if (ret) - goto cleanup_unpin; - } - ret = dev_priv->display.queue_flip(dev, crtc, fb, obj, ring, page_flip_flags); if (ret)
Created attachment 118946 [details] Xorg log The patches don't solve the problem. Note that I couldn't apply the kernel one to the master branch, due to failing patching (I inspected the file, and that code seems to be different from what I can see in your patch). However I could successfuly apply it to the 4.2 branch.
Created attachment 118947 [details] dmesg with 4.2 kernel with patch from comment #3 I am also attaching the dmesg in case it's needed.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/issues/70.
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.