scrolling in chrome leads to distorted images

Created attachment 82530
SNA-issue-4

I'm seeing various screen corruption issues with latest Intel SNA DDX on my Ivy Bridge. On the kernel side, I have 3.10.1, and on X server side I have Ubuntu ppa of xserver-xorg-core 1.13.4~git20130508.

I'm not sure when exactly it started (could be months ago). Switching to UXA makes the issue in bug-intel-ddx-4.png go away, and probably in bug-intel-ddx-3.png, but that one is a bit harder to reproduce.

I'm using mostly GTK2 clients on LXDE environment, without compositing.

Created attachment 82531
SNA-issue-4

Created attachment 82532
SNA-issue-3

SNA-Issue-4 shows a problem on the bottom left (the status bar of PHPstorm is broken by text above)

SNA-Issue-3 show text corruption on the bottom-centre part of the screen, when entering text in text box.

(In reply to comment #2)
> Created attachment 82532 [details]
> SNA-issue-3

This looks like the kernel bug fixed by

commit daa13e1ca587bc773c1aae415ed1af6554117bd4
Author: Chris Wilson <email address hidden>
Date: Fri Jun 28 16:54:08 2013 +0100

    drm/i915: Only clear write-domains after a successful wait-seqno

Can you describe the first issue more clearly, is it only with that application?

The first issue is the only one I can reproduce easily, I'm not sure if it is PHPStorm specific, but it might be.

Basically it's seen only when I scroll that treeview of the application. Initial rendering of the status bar is fine.

Can you check which commit you have of the DDX, there was a various recent bug with scrolling, fixed by

commit 34c9b759fbab8d548108e954d55de38c6f5bec31
Author: Chris Wilson <email address hidden>
Date: Tue Jul 16 19:39:37 2013 +0100

    sna: Note that borderClip region may be more than a singular box

Hmm, I think I just fixed a further bug from

commit 34c9b759fbab8d548108e954d55de38c6f5bec31
Author: Chris Wilson <email address hidden>
Date: Tue Jul 16 19:39:37 2013 +0100

    sna: Note that borderClip region may be more than a singular box

with:

commit a764a6e69b23f644957cf3e4e98868464f458758
Author: Chris Wilson <email address hidden>
Date: Wed Jul 17 10:51:56 2013 +0100

    sna: Fix typo in computing box intersection

Do you mind attaching your Xorg.0.log so that I can check which version you are running?

I tested with a version compiled at 8:50 CET, so it had 34c9b759fbab8d548108e954d55de38c6f5bec31

But right now I tested with current a764a6e69b23f644957cf3e4e98868464f458758, and the problem in PHPStorm is gone.

It looks like the first issue in this bug, is still present.

I have a kernel version a0ab62339af858b63eba0205a583a5a503536da6 (got it from drm-intel-nightly ubuntu mainline builds), and I still saw a very similar problem as with previous sna-issue-3 screenshot.

My DDX is e386ba86ea487a2db62d80a0e60f176e052d6406, do I don't have the latest single commit since that. I'll attach the image of the new issue, it looks slightly different, but that probably is a just in the random garbage differences.

Created attachment 82715
sna-issue-3-new

Could be an unwanted side-effect of

commit 6921abd81017c9ed7f3b2413784068fbc609a0ea
Author: Chris Wilson <email address hidden>
Date: Thu Jul 18 16:21:27 2013 +0100

    sna: Add a fast path for the most common fallback for CPU-CPU blits

in which case please test with current master. Thanks.

Retested.

Sorry, still an issue.

* scratches head

Not sure then. Please can you attach Xorg.0.log to confirm the configuration details, and if you can identify any pattern (i.e. reproduction steps) leading up to the corruption that will be very useful. Thanks.

This is what I use to reproduce a problem from a fresh reboot (drm-intel-nightly 68c6cd3f1312965698b2af5bb08e15807ce9ae2d, DDX 7b1a5024df96070bab70744ad7e7d78a41fb0f72 - current):

- Open Google Chrome (Version 28.0.1500.71)
- Go to http://support.humblebundle.com/customer/portal/articles/754604-torchlight-changelog
- Try selecting text in last three bullet points
- If the right edge of the white bounding box that surronds the main content in the page is obscured by making the window narrower, the problem when selecting text goes away
- Attached image for reference (bug-chrome.png)
- Attached Xorg.log

Created attachment 82823
bug-chrome.png

Created attachment 82824
Xorg.log

Ben confirmed seeing something similar also after updating his kernels to 3.10.3, and only on ivb (not ilk, but then again not exhaustively tested). I've switched to browsing with chromium (rather than just light testing) and have also seen the occasional glitch. I have not yet found a pattern, so it remains elusively unreproducible.

Spotted something that looks like it would be hit by Chromium from time to time:

commit c9d89499806779cd6c62d5d6d34df76279cc5abd
Author: Chris Wilson <email address hidden>
Date: Mon Jul 29 11:51:39 2013 +0100

    sna: Composite region is already in dst drawable space

    So do not offset it again when processing the fallback composite
    operation.

    Regression from commit 6921abd81017c9ed7f3b2413784068fbc609a0ea
    Author: Chris Wilson <email address hidden>
    Date: Thu Jul 18 16:21:27 2013 +0100

        sna: Add a fast path for the most common fallback for CPU-CPU blits

    References: https://bugs.freedesktop.org/show_bug.cgi?id=66990
    Signed-off-by: Chris Wilson <email address hidden>

I'm hoping that we can still find a pattern behind the corruption, otherwise it will remain nigh on impossible to test. :|

I'm away on a vacation. I'll be able to test in a week with the scenario above that was reproducible every time on my machine.

I'm not sure this helps, but I've been seeing what looks like exactly this bug on my Lenovo T430s as well. I first saw it when entering text: the garbled long, horizontal rectangle changed as I typed (my typing was a part of it and/or near it). Like the reporter of this bug, the rectangles often appear as if the width does not match the contents, causing offsetting/slanting of the pixel lines (perhaps just one effect).

It's just been the past few weeks or less (approx.) that I remember noticing it. I am on xf86-video-intel 2.21.13-1 (Arch Linux), and kernel 3.10.2, but I do believe I saw the issue with kernel 3.9.9 as well (and I know I saw it with xf86-video-intel 2.21.12-1, also).

It happens at seemingly random times, and often I just see a random rectangle (mostly in Chromium) with the garbled contents, but it goes away quickly when something changes. The rectangles sometimes look different than described above, but I suspect it is the same cause. I'll try to get a screen capture next time I see it.

I'll attached my Xorg.0.log file, in case that is of help.

Created attachment 83554
Xorg log file

Here's my Xorg log file, in case it helps.

Created attachment 83675
Screenshot showing problem on my Lenovo T430s

OK, I captured a screenshot, finally, of the bug as I've often seen it. I think it looks strikingly similar to the reporter's visual effect. Hope this is of help! Note that this is from my Lenovo T430s (not the older Lenovo that I was using when I reported the unrelated bug 55500 a while back).

Retested with latest DDX (c01c66b), drm-intel-nightly kernel 3224cf6c3ee5ab9c280052c9fbed4f660310c411

Still able to reproduce with the instructions above.

If you are keen, you can try:

the userptr branch from http://cgit.freedesktop.org/~ickle/linux-2.6

and compiling the ddx with ./configure --enable-userptr <usual configure options>

The difference will be subtle, only a path where we need to operate on a busy target will use the userptr directly. At the moment, we will allocate a staging buffer to perform the copy. My feeling is that we are missing some barrier around that staging buffer and the GPU reads garbage instead of the updated content from chromium. So if switching to userptr does fix the corruption, I think that points towards the staging buffer.

*** Bug 67894 has been marked as a duplicate of this bug. ***

I am seeing very similar rendering corruption (in the chrome browser) to those reported by Vedran Rodic. My system is archlinux, with the following key packages

linux 3.10.5-1
xf86-video-intel 2.21.14-2

By reverting to UXA the rendering problems don't seem to appear so this seems to be due to SNA in the current version of xf86-video-intel.

Created attachment 83939
xorg log where graphics corruption was observed (SNA)

Created attachment 83945
xorg log after switching back to UXA

(In reply to comment #27)
> I am seeing very similar rendering corruption (in the chrome browser) to
> those reported by Vedran Rodic. My system is archlinux, with the following
> key packages
>
> linux 3.10.5-1
> xf86-video-intel 2.21.14-2
>
> By reverting to UXA the rendering problems don't seem to appear so this
> seems to be due to SNA in the current version of xf86-video-intel.

If it is any additional help the system has an I3-3220T processor with HD2500 graphics.

$ lspci | egrep -i vga
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09)

Can you please all test whether:

diff --git a/src/sna/sna_composite.c b/src/sna/sna_composite.c
index 58dd356..6f24eeb 100644
--- a/src/sna/sna_composite.c
+++ b/src/sna/sna_composite.c
@@ -520,7 +520,7 @@ sna_composite_fb(CARD8 op,
        if (mask)
                validate_source(mask);

- if (mask == NULL &&
+ if (mask == NULL && 0 &&
            src->pDrawable &&
            dst->pDrawable->bitsPerPixel >= 8 &&
            src->filter != PictFilterConvolution &&

stops the corruption?

Another step in the saga,

commit e8dfc5b3f4ffeec93e52a5319b5a3118edf0e94e
Author: Chris Wilson <email address hidden>
Date: Mon Aug 12 10:33:41 2013 +0100

    sna: Fix destination offset along memcpy composite fallback fastback

    The application of dst_x|y was incorrect, and so the drawing could end
    up in the wrong location for a window.

    References: https://bugs.freedesktop.org/show_bug.cgi?id=66990
    Signed-off-by: Chris Wilson <email address hidden>

Pretty sure this is it! Haven't been able to reproduce my irregular chromium corruption since, but then it was fairly irregular...

No, that's not it, sorry. I can still reproduce it with "SNA compiled from 2.21.14-27-g9645e71".

I'll retest with latest drm-nightly-intel

(In reply to comment #33)
> No, that's not it, sorry. I can still reproduce it with "SNA compiled from
> 2.21.14-27-g9645e71".
>
> I'll retest with latest drm-nightly-intel

Can you also try with the quick little hack from c31

diff --git a/src/sna/sna_composite.c b/src/sna/sna_composite.c
index 58dd356..6f24eeb 100644
--- a/src/sna/sna_composite.c
+++ b/src/sna/sna_composite.c
@@ -520,7 +520,7 @@ sna_composite_fb(CARD8 op,
        if (mask)
                validate_source(mask);

- if (mask == NULL &&
+ if (mask == NULL && 0 &&
            src->pDrawable &&
            dst->pDrawable->bitsPerPixel >= 8 &&
            src->filter != PictFilterConvolution &&

to sanity check that I am barking up the right tree.

Latest git plus this patch applied still has the same corruption.

Thanks, that suggests you have something I haven't seen yet. Ben, what happens with your test case?

No luck for me either.

Elsewhere it has been reported that strange artefacts occur when ring switching on IVB. It is definitely worth testing with current -intel to see if the corruption has changed.

You are right! :) This is fixed on my IVB with current version (intel(0): SNA compiled from 2.21.15-13-ge98cc0b).

Thanks Chris. I'll be optimistic and close this bug now.

I am still experiencing this issue, both on

[ 792.429] (II) intel(0): SNA compiled from 2.21.15-13-ge98cc0b

and on 2.99.901.
I get exact same results as in comment #14.

Platform:
Lenovo Thinkpad X1 (Sandy Bridge/Intel(R) HD Graphics 3000)
Kernel 3.10.5
Google Chrome 28.0.1500.95

*** Bug 68964 has been marked as a duplicate of this bug. ***

Not to be redundant, but I am also still seeing this issue on Arch Linux (on Lenovo T430s) with xf86-video-intel 2.21.15-1.

Looks like it is fixed as of:

(II) intel(0): SNA compiled from 2.99.901-45-g76790db

Can anyone else confirm this?

Confirming.

I've updated video driver from git and I haven't seen any corruptions anymore. But it will take several days to say about this accurately.

I've just seen screen corruption in the latest version of intel driver. But now it is really rare, only one time in two days(was 10-20 times).

Just experienced that weird corruption again - but, as bay said, it is only once in a while - very intermittent and I cannot reproduce it at will.

I am still experiencing corruption as well using a git build (from the day before yesterday) of xf86-video-intel... It's very difficult to reliably reproduce the issue but it's definitely still there.

I've made quite a few minor fixes, none of which ostensibly look like it should fix this issue, but double checking with the current rc kernel (3.12-rc2) and latest xf86-video-intel.git is a must.

Afterwards, you can try enabling (independently, and/or in combination)

#define DBG_NO_UPLOAD_CACHE
#define DBG_NO_UPLOAD_ACTIVE
#define DBG_NO_MAP_UPLOAD

in src/sna/kgem.c and see if any of those prevent the corruption.

I can reproduce it most of the time on http://www.pastebin.com/ now, when clicking on the search box.

Tested on gentoo-sources-3.10.5 and vanilla 3.12-rc3 with xf86-video-intel c724098

It looks like enabling just

#define DBG_NO_UPLOAD_CACHE

is enough to prevent the corruption on 3.12-rc3 (I enabled all 3 options first, then disabled them one by one to pinpoint the right combination).

Finally!

commit a048f436a0210d076fc844404bf56b8b7fcb4b7b
Author: Chris Wilson <email address hidden>
Date: Wed Oct 2 14:59:11 2013 +0100

    sna: Only delete unused io buffers

    Before deleting the io buffer, we need to check that it is not active.
    Currently we check that it is not pending use in the current batch, but
    we also need to double check that it does not have outstanding use by
    the GPU. Failing to do so could mean overwriting the data prior to it
    being read by the GPU, a very small race but often hit!

    Reported-by: Vedran Rodic <email address hidden> # and many others
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66990
    Signed-off-by: Chris Wilson <email address hidden>

Yep, seems to work fine on 3.12.0-rc3 and a048f436. Good work, thanks!

Confirming. I haven't seen any corruptions for a week since I applied the patch.