Bug 94987

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