Fix #80 seems to work. The only side effect I've found so far is that taking screenshots (with gnome-screenshot) takes an "old" screenshot (shows you some old content which was in exactly the same place before) or maybe it gives you only the background wallpaper, etc. Taking screenshots with Gimp works partially too.

Regards

Fix #80 makes dual monitor unusable on my Lenovo T460p (Ubuntu 16.04.1). What kernel version are you folks using?

modesetting makes Chrome hang sometime

Thinkpad X230 with Chrome 52.0.2743.82 

> Fix #80 makes dual monitor unusable

It's not a fix, it's an ugly workaround. #73 is a proper fix.

> What kernel version are you folks using?

I'm on latest stable (4.7.2 right now) from here: http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=M;O=D

> modesetting makes Chrome hang sometime

Never happened to me since Jul, 24.

I am experiencing this issue, and was going to try the fix here: https://bugs.chromium.org/p/chromium/issues/detail?id=606152#c63

Although, the contents of the following dir are:
$ ls /usr/share/X11/xorg.conf.d
10-amdgpu.conf  11-evdev-quirks.conf      50-vmmouse.conf
10-evdev.conf   11-evdev-trackpoint.conf  50-wacom.conf
10-quirks.conf  50-synaptics.conf         51-synaptics-quirks.conf

So, should I create the 20-intel.conf file?

I do appear to have some sort of Intel GPU:
$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09)

#96, yes just create it :)

sudo nano /usr/share/X11/xorg.conf.d/20-intel.conf

Paste this:

Section "Device"
   Identifier  "Intel Graphics"
   Driver      "intel"
   Option      "AccelMethod"  "sna"
   Option      "TearFree"    "true"
   Option      "DRI"    "3"
EndSection

and reboot.

I can confirm that #93 worked, brand new xps 13, upgraded from 14.04 to 16.04

Yup, #93/97 worked for me on a Skylake running Mint 18!

Alas, purging xserver-xorg-video-intel causes nasty, nasty problems later;
I had to reinstall it.
See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1577216

I can get the graphics stable with Linux Kernel 4.6 of backports and non-free firmware, please see http://unix.stackexchange.com/a/307211/16920 There is still a bug there if you need to switch often back and forth between Linux kernel 4.4 and 4.6. My /etc/X11/xorg.conf

    # http://unix.stackexchange.com/a/308709/16920
    Section "Device"
            Identifier "Intel"
            Driver "modesetting"
    EndSection

    ## Bugs 
    # 1. LK 3.16 will fail now but LK 4.6 will work. TODO in the thread http://unix.stackexchange.com/a/308709/16920

I've seen a few fixes, but then they cause other issues with other programs.  Modeset supposedly is kicking some users back to the login screen and isn't stable.  So what is the supposed fix now?  The flashing has almost triggered epilepsy and I can't risk this anymore.  I'm still on Windows for now until this is all fixed.

From what I've seen so far:  Modeset causes a crash in some situations, SNA causes screenshot issues, what is left?

All these bandaids are a big pain in the butt.

I'm using modesetting for a while on my Thinkpad T460s with Ubuntu 16.04. Only noticeable side-effects are:
- VGA output doesn't work (through displayport adapter)
- Gnome's lock screen isn't shown 99% of the times. When locked, the screen show the last known image of the desktop (like my e-mail) but I can type my password blindly to unlock the screen.

Anyone having crashes on modesetting?

BTW, I'm on the latest BIOS. This might make a difference.

I don't want to have those kind of side effects just to make Chrome happy.

Especially with the lock screen potentially showing the last image.  That's silly just for a web browser.  VGA I need to have, for when I'm presenting at a work place.

I don't know if this helps but I have been able to fix this by adding --disable-gpu to the chrome command line.  However, I still see the issue in Spotify for Linux where I don't see a way to pass parameters to the underlying web ui.

Version 53.0.2785.143 Built on Ubuntu , running on Ubuntu 16.04 (64-bit)
With this update, the issue of flicker still occurs, just somewhat less frequently. There is NO fucking flicker on my Dell:
Version 37.0.2062.120 Ubuntu 12.04 (281580) (64-bit) Why??

Well the Dell you mention is running far older software, older OS, older drivers, and older Chrome, they didn't have the issue yet, that's why.

Also as to the comment 106, disabling GPU acceleration is NOT a true fix.  That's a bad bandaid that no one should have to do in this day and age.  Maybe 10 years ago, but these days disabling GPU acceleration isn't a good fix.  It'll slow down things.

We need a REAL fix, and the more I sit here waiting for the fix, the more I realize, it's time to just switch to Firefox, and if any Chrome devs are upset by that comment, then you had your chance.  Yes I'm bitter now, this is going on half a year.

Guys.. It's a bug in intel video driver (sna) .. This is not chrome's fault. You can switch to xua, use modesetting or fiddle with 20-intel.conf like said before.. You have plenty of options..

We have already learned though that changing these drivers cause other unpredictable results.  Since Firefox does not have the flickering issue nor does any other browser other than Chrome, then the only option would be to change the browser to not cause other results with the rest of the computer.

Do whatever you want :) Google is not going to fix this, since it's not their issue.

I personally have no problems with the 20-intel config file options.. Screenshots and all works just fine.

What about your lock screen?  Does it properly work?  And what window manager are you using?

lockscreen works just fine. I'm using unity with lightdm.

So theres no sense to keep this conversation here, theres a bug report on
some intel website ?

El sáb., 8 oct. 2016 15:57, joakimk… via monorail <
monorail+v2.2226764534@chromium.org> escribió:

I would hope so.  But in my 16 years experience doing bug reports with devs, it turns into a finger pointing contest on issues like this. They will say it's chrome because only chrome has an issue. Chrome devs will say it's an Intel driver issue because workarounds fix it. 

I propose a cat fight between intel video and google chrome people!!


Le samedi 8 octobre 2016, maceac… via monorail <
monorail+v2.2143246845@chromium.org> a écrit :

Going to chrome://flags and setting GPU Rasterization to "Force-enabled for all layers" has completely solved this issue for me, without the need to edit xorg.conf in any way. YMMV, of course, but I recommend giving it a try before messing around with your drivers.

Had this issue, setting GPU Rasterization to "Force-enabled for all layers" as suggested above fixed it. Thanks for the suggestion.

Setting GPU Rasterization to "Force-enabled for all layers" alleviated the symptoms (flickering and flashing). This is using Chrome on a ThinkPad X1 Carbon running Ubuntu 16.04 LTS.

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

Freedesktop Bug here: https://bugs.freedesktop.org/show_bug.cgi?id=94987

I can replicate with:

Ubuntu 16.04.1 (xenial)
Chrome 55.0.2883.87
Kernel: 3.10.18

X.Org X Server 1.18.4
xorg-server 2:1.18.4-0ubuntu0.2 
Current version of pixman: 0.33.6

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)

Now, is this issue in any way possibly related to this other issue I have encountered in Chrome?  This issue started at the same exact time the flickering issue started.

Sometimes pulldown menus don't render and are completely blank.  I have currently the rasterization set to force enable on all layers, (testing out to see if that fix does indeed work at all for the flickering---I don't want to pull out my drivers yet or modify them as a solution).

https://www.youtube.com/watch?v=PaRTD9LejMw

I see this at well ^

I also see the issues with drop downs. Chrome 55, Ubuntu 16.04, ThinkPad X1 Carbon.

Should I go ahead and start another bug-report, or do we feel it's related to the flickering issue?  So far I haven't seen flickering since enabling rasterization on all layers (I have only used it for an hour so far), but the pull down issue DOES remain.

That's a good point. I have enabled rasterization on all layers and the primary issue in this bug-report seems fixed. Perhaps a new one to address the drop-downs?

Hmm, I'll wait for later tonight to see what the consensus is on a separate bug report, if they aren't related.  It seems like it may not be, but have another underlying bug.  If I see no objection to another bug report, I'll make another.  For now I'll just wait.

Woops, I just had the screen flash on wftv's website, so the above "fix" did not work.  It took longer for it to show up but it did flash.

Thinkpad W541.

I really hate to be a bother, but SNA and DRI 3 fix for Xorg has FIXED the issue permanently, and has NOT had any issues whatsoever regarding screenshots.  I had been looking and picking for issues, but none so far.

So, I can without a doubt, confirm that the fix is comment #63.

I did NOT however do any of those flags.  It's working just fine without the flags.  Only thing I still have enabled is force rasterization on all layers, and that likely isn't even required either, but it helps Google Maps performance as is.

I'm experiencing the issue with very lightweight sites (e.g. Wikipedia), where the bookmarks bar flickers. Filed a separate report at #671540, but it's the same issue.

Dell E7450 laptop with Intel Graphics, Ubuntu 16.04.1, Chrome maximized. The easiest workaround is to "maximize" the window by resizing it manually.

Trying to summarize 131 comments:

- It sounds like there are bugs in the intel driver that we seem to tickle with our one-copy uploads. Not clear to me if it's a synchronization problem or a data consistency problem.
- It's reported that --enable-zero-copy avoids the problem which points at one-copy triggering it.
- Also reported that --force-gpu-rasterization avoids the problem. Since in this case we don't need to upload this correlated with one-copy uploads triggering the problem. (Users should note gpu rasterization is experimental on linux and not expected to be bug free yet.)
- By using --disable-gpu (or disabling hardware acceleration in chrome://settings) the issue is avoided, by not using the intel GL driver at all of course.
- Other flags listed would be at best tangentially related and perhaps happen to disable GPU compositing entirely, or were combined with other things that had an effect.
- Comment #80 solves this by changing the behaviour in the driver.

Typically we avoid buggy linux drivers by blacklisting them, which produces the same result as --disable-gpu. Chromebooks also use intel drivers but presumably we're not seeing this there.

I'm assigning to reveman@ as the most knowledgable person about one-copy implementation, if anyone can find a workaround it's him.

I actually have determined that this issue at least on my Haswell, was not resolved by using Rasterization (and that introduced some other graphical hiccups)..

Literally my only fix was to enable DRI 3 and SNA.  Ever since then I've had zero issues, and in fact, improved graphical performance and all is well in Haswell land now for me.  Not one bit of flickering.  Chrome itself is literally on all default settings (minus overide rendering lists, that's the only one enabled).

With that, this is an Xorg bug because before I made changes to the Xorg settings, even Firefox had some flickering (mostly on Imgur only) as well, but far far rarer.

Thanks for summarizing, Dana!

Another important bit - the issue only occurs if Chrome is maximized or running in full-screen mode. I have no idea about how rendering internals work, but would it be possible to preserve the hardware-accelerated rendering from windowed mode in maximized mode? Again, this may be totally off.

I'm surprised that --enable-zero-copy makes a difference as without native GMBs one-copy and zero-copy really does the same thing at the driver level (a texture upload).

One difference between one-copy and zero-copy is that one-copy supports partial updates. Can someone check if passing --disable-partial-raster to chrome makes a difference?

I've discovered that when I'm now experiencing this issue too on a brand
new Dell Inspiron new 15 5567. It's rather annoying.

While I'm here since getting a notification, has anyone else noticed, with any of the your preferred method of fixes, that the tooltip popups sometimes are corrupted, or all black?

Yes, I'm getting the corrupted/black tooltips as well. 

Thanks for the quick response on that.  I'm going to do some more testing on that on my side, as I don't think it's necessarily related to the bug in this post, but without the fixes we apply, it doesn't seem to happen until AFTER we apply the fixes.  Reason I feel it's not related, is because on my AMD Radeon 7500 on my desktop, it has the same tooltip bug that our Intel GPU's show after we apply any reasonable fix that prevents the flickering.

(Well, maybe it is related in a way then?)

Yes! My tooltips are sometimes corrupted. It's if the current tooltip is
larger than the previous one.

 Issue 689692  has been merged into this issue.

Raising to P1 based on the merged-in issue

I suspect the default Intel driver in Ubuntu 16.04 is also responsible for a lot of Chrome 56.0.2924.87 (64-bit) instability on an out-of-the-box install. I had tabs and extensions crashing very frequently until I switched to SNA and enabled DRI3 and the stability seems to have improved, haven't had issues so far.

Tried the idea in comment 146 on my laptop running Trusty with the Xenial HWE stack. It helped, but the problem doesn't entirely go away.

xorg.conf.d fragment I used:

Section "Module"
    Load "dri3"
EndSection

Section "Device"
    Identifier  "Intel Graphics DRI 3"
    Driver      "intel"
    Option      "DRI" "3"
EndSection

# Note that AccelMethod is set to "sna" in another config fragment.

Also, the issue is *not* restricted to full-screen mode. It definitely occurs on non-full-screen maximized windows. Uncertain if it occurs in non-maximized windows.

'Option      "TearFree" "false"' seems to help a *lot*.

TearFree=false makes everything else look horrible.

On an x1v4, this seems to solve the problem entirely:

Section "Device"
    Identifier  "Intel Graphics DRI Settings"
    Driver      "intel"
    Option      "DRI" "2"
    Option      "AccelMethod" "sna"
    Option      "TearFree" "true"
EndSection

(And forget the dri3 module bits.)

Well, no. But it makes things a lot better.

It might be worth looking at modesetting too, since the issue doesn't seem to appear there for a number of users on this thread:
https://bugs.chromium.org/p/chromium/issues/detail?id=606152#c73

I'll look into KMS.

Also worth pointing out, Option      "DRI" "2" introduces a bug of its own: alt-tab appears to break. That is, alt-tabbing between Chrome windows causes them to stop drawing graphics to the screen. Another alt-tab and back causes drawing to resume.
Any keyboard/mouse input provided to the window while in the 'frozen' state takes effect as normal, with the results becoming visible when drawing resumes.

Just tried KMS. It causes Cinnamon to fall back to software rendering mode. So no sale.

My mistake. Figured out how to get KMS working on Trusty.

Interesting, that may be hardware dependent. I get acceleration (and no chrome flickering) under modesetting with this:

$ inxi -GSx
System:    Host: hostname Kernel: 4.4.0-64-generic x86_64 (64 bit gcc: 5.4.0)
           Desktop: Cinnamon 3.2.7 (Gtk 3.18.9-1ubuntu3.1) Distro: Linux Mint 18.1 Serena
Graphics:  Card: Intel Sky Lake Integrated Graphics bus-ID: 00:02.0
           Display Server: X.Org 1.18.4 drivers: (unloaded: fbdev,vesa)
           Resolution: 3200x1800@59.98hz
           GLX Renderer: Mesa DRI Intel Iris Graphics 540 (Skylake GT3e)
           GLX Version: 3.0 Mesa 12.0.6 Direct Rendering: Yes

As you say it's not a solution for everyone, although it might be a clue for what's going on.

Modesetting causes Chrome to disable software acceleration. This is a serious problem.

Uh, make that "switch to software acceleration".

Is that the effects of the rendering whitelist?

chrome://gpu on chromium 56.0.2924.76 with modesetting:

Graphics Feature Status
Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Native GpuMemoryBuffers: Software only. Hardware acceleration disabled
Rasterization: Software only. Hardware acceleration disabled
Video Decode: Software only, hardware acceleration unavailable
Video Encode: Hardware accelerated
VPx Video Decode: Software only, hardware acceleration unavailable
WebGL: Hardware accelerated
WebGL2: Hardware accelerated

With chrome://flags override software rendering list:

Graphics Feature Status
Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Native GpuMemoryBuffers: Software only. Hardware acceleration disabled
Rasterization: Software only. Hardware acceleration disabled
Video Decode: Hardware accelerated
Video Encode: Hardware accelerated
VPx Video Decode: Hardware accelerated
WebGL: Hardware accelerated
WebGL2: Hardware accelerated

Nope, overriding the whitelist doesn't help.

... does Chrome hardware acceleration require the XVideo extension, perchance?

Scratch that. No matter what I do, I can't get it to work under modesetting.

(This is on a Skylake machine.)

Of note:

Log Messages
GpuProcessHostUIShim: The GPU process crashed!
GpuProcessHostUIShim: The GPU process crashed!

crbug/698055

Kabylake machine here having flickering specially visible on dark backgrounds, using 57.0.2987.133 (64-bit). No matter if fullscreen or not.
Additional problem (might not be related): Tab opening and closing ist very slow in normal mode (no problem in incognito mode, so surely extension related but still a new problem with this version of chrome). 

 Issue 626506  has been merged into this issue.

 Issue 594940  has been merged into this issue.

Issue 610108 has been merged into this issue.

@#164: Chrome is running really slowly for you? I think I might have that bug! It happens for me every time I try to put a chrome window on more than one desktop. It didn't happen on my old linux machine.

reveman@ this issue has been P1 for a long time.  What are the next steps here?

Thanks!

Issue 671540 has been merged into this issue.

Issue 728619 has been merged into this issue.

I've had my issue merged into this as a duplicate (affecting Windows 10 x64). Has anyone else seen similar things in Windows and know of potential workarounds - or is it simply a case of toggling various GPU settings?

I haven't seen this on Windows, except on really old buggy cards.

This is on a Dell XPS, they were released about 18 months ago, not sure that would be considered an old card?

Nope

I've attached a recording of what I'm seeing in Windows. Only ever affects the DevTools console view, and it doesn't flicker (but it does change depending on what my mouse is over). Machine details:

Machine: Dell XPS 15 9550
OS: Windows 10 Pro 64-bit
Display: Intel HD Graphics 530 
Render: NVIDIA GeForce GTX 960M

Deleted: Chrome DevTools.gif 802 KB

	Chrome DevTools.gif 802 KB View Download

Bump. Any ETA here? This makes using Chrome seriously unpleasant on Ubuntu Xenial. (Or Ubuntu Trusty with the Xenial HWE.)

It's also making Chrome pretty unpleasant on Windows 10 x64

Easy there mate, was only logged 16 months ago!

I've un-duped Issue 728619 from this issue, as that seems to be Windows + GPU Rasterization configuration.

Can anyone please confirm if --disable-partial-raster from comment #135 makes a difference here?  Thanks.

I just checked. Unfortunately, it doesn't.

Another workaround could be turning of v-sync via the vblank_mode parameter.
Even though this introduces the possibility of tearing but in my case I didn't experienced any so far.
So maybe it is worth a try. This parameter can be set permanently for all programs or per-program via the {$HOME}/.drirc file. This makes it very convenient as the flags for native-gpu-buffer usage seems to be command-line only and therefore require the editing of the .desktop file every time the (a) effected program was updated.
A short blog-post compiling several occurrences of this issue can be found at:
https://solutions4linux.blogspot.jp/2017/11/workaround-for-flickering-chrome-and.html 

Deleted: .drirc 131 bytes

.drirc 131 bytes Download

Can anyone confirm if a recent driver with the change noted in https://bugs.freedesktop.org/show_bug.cgi?id=94987#c25 fixes this? If so, we can disable GPU acceleration on drivers prior to that fix.

@piman, the fix was in Linux kernel (https://github.com/torvalds/linux/commit/7aa6ca61ee5546d74b76610894924cdb0d4a1af0), instead of Mesa. 

@#187, oh, ok, right. Question still stands :)

We have sophisticated way to verify each fix of Mesa, but we don't know how to do this with Linux kernel. I wonder if someone else can help here or tell us the instructions to build an old kernel and replace the one in system. 

Don't mesa versions need to be matched with appropriate kernel versions? If so, we can blacklist based on mesa version, assuming that if you have an old mesa version, you probably have an old kernel as well.

We should figure out how to blacklist for this, but since this isn't being worked on, it shouldn't be a P1.