Created attachment 123024 [details] xorg log Dell XPS 15 9530 kernel 4.6.0-rc3-00182-gb9f5dba (and many older versions) Mesa 11.2.0 intel driver: SNA compiled from 2.99.917-634-g81029be xserver 1.18.3 google chrome 49.0.2623.112 (with default flags in flags://) and when viewing youtube in fullscreen there is flickering visible depending on mouse movements (mouse over youtube overlayed texts/menus). Problem is visible here: http://ixion.pld-linux.org/~arekm/p2/intel-bug-x1.avi This problem is there for many months, so older versions of kernel, mesa, intel ddx, xserver, google chrome were also exhibiting this behaviour here.
Dirty cache lines are here again. To rule out the ddx mocs, can you please try diff --git a/src/sna/gen7_render.c b/src/sna/gen7_render.c index f707d39..a3c5007 100644 --- a/src/sna/gen7_render.c +++ b/src/sna/gen7_render.c @@ -163,7 +163,7 @@ static const struct gt_info hsw_gt2_info = { 1 << HSW_PS_SAMPLE_MASK_SHIFT, .urb = { 256, 1664, 640, 8 }, .gt = 2, - .mocs = 5, + //.mocs = 5, }; static const struct gt_info hsw_gt3_info =
See also bug 80948
(In reply to Chris Wilson from comment #1) > Dirty cache lines are here again. To rule out the ddx mocs, can you please > try > > diff --git a/src/sna/gen7_render.c b/src/sna/gen7_render.c > index f707d39..a3c5007 100644 > --- a/src/sna/gen7_render.c > +++ b/src/sna/gen7_render.c > @@ -163,7 +163,7 @@ static const struct gt_info hsw_gt2_info = { > 1 << HSW_PS_SAMPLE_MASK_SHIFT, > .urb = { 256, 1664, 640, 8 }, > .gt = 2, > - .mocs = 5, > + //.mocs = 5, > }; > > static const struct gt_info hsw_gt3_info = Doesn't help unfortunately.
Ok, try patching it out of mesa as well: diff --git a/src/mesa/drivers/dri/i965/brw_defines.h b/src/mesa/drivers/dri/i965/brw_defines.h index 60b696c..522a75a 100644 --- a/src/mesa/drivers/dri/i965/brw_defines.h +++ b/src/mesa/drivers/dri/i965/brw_defines.h @@ -2864,13 +2864,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) If that fails, we have to start questioning the kernel.
Unfortunately it fails (ddx + mesa patches applied).
Can you please try (kernel): diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 6ce2c31..4caccd2 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -3926,12 +3926,8 @@ out: * object is now coherent at its new cache level (with respect * to the access domain). */ - if (obj->cache_dirty && - obj->base.write_domain != I915_GEM_DOMAIN_CPU && - cpu_write_needs_clflush(obj)) { - if (i915_gem_clflush_object(obj, true)) - i915_gem_chipset_flush(obj->base.dev); - } + if (i915_gem_clflush_object(obj, true)) + i915_gem_chipset_flush(obj->base.dev); return 0; }
No flickering with this patch (+ ddx + mesa patch). (I'm seeing some stalls of browser for about half a second but I guess it's unrelated)
Next up try: diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 6ce2c31..2897f67 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -4491,6 +4491,7 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj, obj->fence_reg = I915_FENCE_REG_NONE; obj->madv = I915_MADV_WILLNEED; + obj->cache_dirtry = true; i915_gem_info_add_obj(obj->base.dev->dev_private, obj->base.size); }
mesa patch dropped and i915_gem_clflush_object(obj, true)... patch applied -> no flickering mesa patch dropped, i915_gem_clflush_object patch dropped, obj->cache_dirtry = true; applied -> flickering exists
Does this help ? (xf86-video-intel) diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c index 80b658a..a7429e8 100644 --- a/src/sna/sna_display.c +++ b/src/sna/sna_display.c @@ -6454,7 +6454,7 @@ sna_page_flip(struct sna *sna, if ((sna->flags & (data ? SNA_HAS_FLIP : SNA_HAS_ASYNC_FLIP)) == 0) return 0; - kgem_bo_submit(&sna->kgem, bo); + kgem_scanout_flush(&sna->kgem, bo); sigio = sigio_block(); for (i = 0; i < sna->mode.num_real_crtc; i++) { @@ -8789,7 +8789,7 @@ void sna_mode_redisplay(struct sna *sna) continue; sna_crtc_redisplay(crtc, &damage, bo); - kgem_bo_submit(&sna->kgem, bo); + kgem_scanout_flush(&sna->kgem, bo); arg.crtc_id = __sna_crtc_id(sna_crtc); arg.fb_id = get_fb(sna, bo, @@ -8889,7 +8889,7 @@ disable1: arg.flags = DRM_MODE_PAGE_FLIP_EVENT; arg.reserved = 0; - kgem_bo_submit(&sna->kgem, new); + kgem_scanout_flush(&sna->kgem, bo); sigio = sigio_block(); for (i = 0; i < sna->mode.num_real_crtc; i++) {
Sorry, try diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c index 80b658a..291b8f0 100644 --- a/src/sna/sna_display.c +++ b/src/sna/sna_display.c @@ -6454,7 +6454,7 @@ sna_page_flip(struct sna *sna, if ((sna->flags & (data ? SNA_HAS_FLIP : SNA_HAS_ASYNC_FLIP)) == 0) return 0; - kgem_bo_submit(&sna->kgem, bo); + kgem_scanout_flush(&sna->kgem, bo); sigio = sigio_block(); for (i = 0; i < sna->mode.num_real_crtc; i++) { @@ -8789,7 +8789,7 @@ void sna_mode_redisplay(struct sna *sna) continue; sna_crtc_redisplay(crtc, &damage, bo); - kgem_bo_submit(&sna->kgem, bo); + kgem_scanout_flush(&sna->kgem, bo); arg.crtc_id = __sna_crtc_id(sna_crtc); arg.fb_id = get_fb(sna, bo, @@ -8889,7 +8889,7 @@ disable1: arg.flags = DRM_MODE_PAGE_FLIP_EVENT; arg.reserved = 0; - kgem_bo_submit(&sna->kgem, new); + kgem_scanout_flush(&sna->kgem, new); sigio = sigio_block(); for (i = 0; i < sna->mode.num_real_crtc; i++) { instead
All patches reverted (from mesa, kernel, ddx). Only patch from comment #11 applied. Flickering still exists.
Drat. Best idea I had so far. Likely no effect, but do please try: diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 6ce2c31..1b296e2 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -54,6 +54,9 @@ static bool cpu_cache_is_coherent(struct drm_device *dev, static bool cpu_write_needs_clflush(struct drm_i915_gem_object *obj) { + if (obj->base.write_domain == I915_GEM_DOMAIN_CPU) + return false; + if (!cpu_cache_is_coherent(obj->base.dev, obj->cache_level)) return true; @@ -1080,7 +1083,6 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data, * perspective, requiring manual detiling by the client. */ if (obj->tiling_mode == I915_TILING_NONE && - obj->base.write_domain != I915_GEM_DOMAIN_CPU && cpu_write_needs_clflush(obj)) { ret = i915_gem_gtt_pwrite_fast(dev, obj, args, file); /* Note that the gtt paths might fail with non-page-backed user @@ -3926,10 +3928,8 @@ out: * object is now coherent at its new cache level (with respect * to the access domain). */ - if (obj->cache_dirty && - obj->base.write_domain != I915_GEM_DOMAIN_CPU && - cpu_write_needs_clflush(obj)) { - if (i915_gem_clflush_object(obj, true)) + if (cpu_write_needs_clflush(obj)) { + if (i915_gem_clflush_object(obj, obj->cache_dirty)) i915_gem_chipset_flush(obj->base.dev); }
All patches reverted. #13 applied. Flickers unfortunately :(
This issue is also on the chrome bug tracker: https://bugs.chromium.org/p/chromium/issues/detail?id=606152 And the ubuntu bug tracker: https://bugs.launchpad.net/xorg-server/+bug/1586539 The current workaround is to use UXA rather than SNA; something chrome does makes SNA unhappy.
Any chances someone will finally fix this very annoying bug?
Hm, seems that to reproduce the issue kde "desktop effects" need to be disabled. Best to start freshly with that disabled ("enable desktop effects at startup" off and reboot) already because switching it on/off makes issue hard to reproduce.
kernel 4.9rc3 SNA compiled from 2.99.917-722-g714052f (oct 24 2016) mesa 13.0 google-chrome-54.0.2840.90 and problem is still there. alt+shift+f12 (enable/disable desktop effects) under kde4 cures the problem (even after switching it off again)
Just some updated information that I hope is useful. This issue is still occurring. See these bugs for more info as well: Ubuntu Bug here: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1586539 Chorimium Bug here: https://bugs.chromium.org/p/chromium/issues/detail?id=606152#c63 I can replicate with: X.Org X Server 1.18.4 xorg-server 2:1.18.4-0ubuntu0.2 Current version of pixman: 0.33.6 Ubuntu 16.04.1 (xenial) Chrome 55.0.2883.87 Kernel: 3.10.18 MESA info: Extended renderer info (GLX_MESA_query_renderer): Vendor: Intel Open Source Technology Center (0x8086) Device: Mesa DRI Intel(R) Bay Trail (0xf31) Version: 11.2.0 Accelerated: yes Video memory: 1536MB Unified memory: yes Preferred profile: core (0x1) Max core profile version: 3.3 Max compat profile version: 3.0 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.0 Related package information: http://pastebin.com/6A5ebWTJ Video information: *-display description: VGA compatible controller product: Atom Processor Z36xxx/Z37xxx Series Graphics & Display vendor: Intel Corporation physical id: 2 bus info: pci@0000:00:02.0 version: 0e width: 32 bits clock: 33MHz capabilities: pm msi vga_controller bus_master cap_list rom configuration: driver=i915 latency=0 resources: irq:104 memory:d0000000-d03fffff memory:c0000000-cfffffff ioport:1000(size=8)
Jari, I guess this one can have its priority demoted as there's a few workarounds as mentioned in this summarizing comment? https://bugs.chromium.org/p/chromium/issues/detail?id=606152#c132
Without knowing how priorities are set, fresh installs of linux on intel hardware show this bug, and one of the workarounds needs to be manually applied for chromium to work properly out of the box. The chrome devs mentioned driver blacklisting as a possible solution in the chrome bug report, so prioritizing a fix instead would be amazing.
(In reply to Benjamin Gemmill from comment #21) > Without knowing how priorities are set, fresh installs of linux on intel > hardware show this bug, and one of the workarounds needs to be manually > applied for chromium to work properly out of the box. Fresh installs of which distribution versions? > The chrome devs mentioned driver blacklisting as a possible solution in the > chrome bug report, so prioritizing a fix instead would be amazing.
The problem seems to affect fresh installs of Ubuntu 16.04 and variants (I use Mint): https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1586539
(In reply to Benjamin Gemmill from comment #23) > The problem seems to affect fresh installs of Ubuntu 16.04 and variants (I > use Mint): > https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/ > 1586539 Sure, but Highest priority seems to be reserved for regressions that don't have a workaround yet.
commit 7aa6ca61ee5546d74b76610894924cdb0d4a1af0 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Nov 7 16:52:04 2016 +0000 drm/i915: Mark CPU cache as dirty when used for rendering
Hey Chris, Thanks for fixing this - do you know what version/release it has been resolved in? I want to check with the package maintainers for my distro to try and get it included.
just use drm-tip here.
I'm seeing this issue with google-chrome, kernel 4.14.103-rt55, debian stretch Mesa 18.2.8-2~bpo9+1 (https://packages.debian.org/source/stretch-backports/mesa) 00:02.0 VGA compatible controller: Intel Corporation 8th Gen Core Processor Gaussian Mixture Model Subsystem: Intel Corporation 8th Gen Core Processor Gaussian Mixture Model Kernel driver in use: i915 Kernel modules: i915 xserver-xorg 7.7+19 google-chrome-stable 76.0.3809.100-1 Workaround: Add --disable-gpu-driver-bug-workarounds and --enable-native-gpu-memory-buffers flags to /usr/share/applications/google-chrome.desktop. Exec=/usr/bin/google-chrome-stable --disable-gpu-driver-bug-workarounds --enable-native-gpu-memory-buffers %U
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.