Please attach your Xorg.0.log, it makes me feel happier. Can you snapshot your full chrome://settings and chrome://flags pages so that I can duplicate your settings?

Created attachment 100826 [details]
Xorg.0.log

I've pressed "Reset all to default" on chrome://flags, then enabled "Override software rendering list".

Settings:
Appearance:
theme - oxygenlike grey
Use system title bar and borders - enabled
System ("Advanced settings"):
Use hardware acceleration when available - enabled

I can make a lot of screenshots, if really neccessary.

Haven't yet started to try and reproduce this, but if you can a chance please try and bisect it. (I guess it will either be userptr or io.)

Found one issue elsewhere testing BLT:

commit 53c1faa5093f8a0c969e3ebe9f27ee1ce5137e14
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Jun 11 07:59:41 2014 +0100

    sna: Mark the GPU as all damaged when discarding CPU bo during uploads
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

which feels relevant here.

Probably fixed by:
commit ffe067705b524930d243b18e97508219ed26390c
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Jun 12 09:52:50 2014 +0100

    sna: Try to use CPU uploads before BLT uploads
    
    As the BLT upload implies a sync (and a likely GPU boost), only do so if
    we cannot do an immediate upload with the CPU, either directly to
    backing memory or through the GTT.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

The bug is still present in current git master.
Sorry, I don't have enough free time to bisect right now.

Drat, had hoped the recent fixes would have been the ones. On the off chance, are you using DRI3? But overwise I have bug 79999.

(In reply to comment #8)
> Drat, had hoped the recent fixes would have been the ones. On the off
> chance, are you using DRI3?
[    17.090] (EE) intel: Failed to load module "dri3" (module does not exist, 0)
Looks like I'm not using dri3.

Another problem: steam ui flickers. And a game launched from steam flickers.

But if I switch from OpenGL compositing to XRender (KWin), all these bugs (in chromium, steam, games) go away.

Also, all these problems are regressions since 2.99.911

Sigh.

Please try


diff --git a/src/sna/sna_dri2.c b/src/sna/sna_dri2.c
index efc790f..3d3c50d 100644
--- a/src/sna/sna_dri2.c
+++ b/src/sna/sna_dri2.c
@@ -1485,6 +1485,8 @@ can_xchg(struct sna * sna,
        WindowPtr win = (WindowPtr)draw;
        PixmapPtr pixmap;
 
+       return false;
+
        if (draw->type == DRAWABLE_PIXMAP)
                return false;
 
to disable xchg. If that is happening KDE is not unredirecting fullscreen windows and there is a race between the compositor reading from a texture and the GL app rendering it their fbo.

Oh, you probably actually need http://patchwork.freedesktop.org/patch/27429/ for the xchg bug. :|

(In reply to comment #10)
> Sigh.
> 
> Please try
> 
> 
> diff --git a/src/sna/sna_dri2.c b/src/sna/sna_dri2.c
> index efc790f..3d3c50d 100644
> --- a/src/sna/sna_dri2.c
> +++ b/src/sna/sna_dri2.c
> @@ -1485,6 +1485,8 @@ can_xchg(struct sna * sna,
>         WindowPtr win = (WindowPtr)draw;
>         PixmapPtr pixmap;
>  
> +       return false;
> +
>         if (draw->type == DRAWABLE_PIXMAP)
>                 return false;
>  
> to disable xchg. If that is happening KDE is not unredirecting fullscreen
> windows and there is a race between the compositor reading from a texture
> and the GL app rendering it their fbo.

Unredirection is configurable, and usually I had that option enabled, but...
https://git.reviewboard.kde.org/r/111476/

Disabling xchg fixes everything. But Steam isn't fullscreen.

I'll test that xorg patch soon.

(In reply to comment #12)
> Unredirection is configurable, and usually I had that option enabled, but...
> https://git.reviewboard.kde.org/r/111476/

That's asinine! The reason they give is that flash using ShmPutImage is not syncing to the screen is good enough reason to force everything to be copied again. And they justify that because they don't understand how compositors and display servers work...

Seriously, just use TearFree and turn off KDE's vsync.

(In reply to comment #13)
> (In reply to comment #12)
> > Unredirection is configurable, and usually I had that option enabled, but...
> > https://git.reviewboard.kde.org/r/111476/
> 
> That's asinine! The reason they give is that flash using ShmPutImage is not
> syncing to the screen is good enough reason to force everything to be copied
> again. And they justify that because they don't understand how compositors
> and display servers work...
> 
> Seriously, just use TearFree and turn off KDE's vsync.

Not only flicker. There was many bugreports about kwin and even client applications crashing when unredirection is enabled. Though I've never seen any crashes myself, on old laptop with HD 3000, on new with HD 4400.

Last time i tried TearFree it signigicantly slowed games down (with working fullscreen unredirection and xrender compositing). Ok, I'll give it another try.

Patch for xorg doesn't fix anything.

Strangely enough, bugs.fd.o doesn't have many reports of clients crashing unredirected either. One day, KDE devs will talk to the rest of us...

Anyway, TearFree has come along way, to the point where now I'd feel comfortable about enabling it by default.

Found one issue with GLXPixmaps - I don't know if Chromium also uses those for some elements of UI, hopefully it does and

commit 243bd26ad31776b2dc45563107e669cf7b45fd91
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Jun 15 21:42:10 2014 +0100

    sna: Clear our private hints about front rendering exported bo
    
    Unlike GLXWindows, GLXPixmaps are rendered directly into, without a
    staging copy. Therefore we must treat those carefully when exported and
    clear our hints everytime control passes back to the Client.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79999
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

would explain the missing redraws.

Didn't test latest commits from master yet..

This bug isn't present on another machine with exactly the same software configuration, but with different gpu:
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)

driver v 2.99.912

Oh, could that just be the gpu whitelist in Chromium disabling features? No, you manually disable that. Hmm. I don't have a hsw on my desk, so the more details you can provide would be great (assuming that it is gpu/driver and not some subtle Cr config).

(In reply to comment #19)
> Oh, could that just be the gpu whitelist in Chromium disabling features? No,
> you manually disable that. Hmm. I don't have a hsw on my desk, so the more
> details you can provide would be great (assuming that it is gpu/driver and
> not some subtle Cr config).

Oops, sorry. Software configuration isn't the same. UXA was specified in xorg.conf. With SNA the bug is here too.

Good, at least it is behaving consistently. Since xchg is active, that implies a compositor. Which?

Using KDE, I can lose the Chromium menu, due to a single sna_dri2_xchg().

The behaviour is as far as I can tell that kwin doesn't update it source after the menu creates and renders its window. The source is meant to updated after an invalidation by glXBindTexImageEXT.

The responsible function seems to be kwin/glxbackend.cpp:

void GlxTexture::onDamage()
{
    if (options->isGlStrictBinding() && m_glxpixmap) {
        glXReleaseTexImageEXT(display(), m_glxpixmap, GLX_FRONT_LEFT_EXT);
        glXBindTexImageEXT(display(), m_glxpixmap, GLX_FRONT_LEFT_EXT, NULL);
    }
    GLTexturePrivate::onDamage();
}

so kwinrc:

[Compositing]
GLStrictBinding=true

should fix the issue (but I don't know the full implications of GLStrictBinding). Indeed it does.