Bug 37990

Are the artifacts visible in a screenshot? If so can you attach a screenshot or otherwise a photograph? Or can you describe the artifact? Is it just stale rendering?

If it gets redraw after damage, it is likely to be stale and not visible in a screenshot. There are a number of issues at play, with various bugs in both Xorg and the driver over time. Can you attach your Xorg.log?

Created attachment 47605 [details]
screenshot

Created attachment 47606 [details]
Xorg.log

As you can see artifacts are visible on screenshot. They disappear disappear only on complete window redraw and looks like this artifact related to concret window not whole screen.

Ok, that the bad rendering is in system memory and read back in a screenshot is a little disturbing. I think it rules out

commit 895a46e8ff70195c1a4bdccbeb652e330376f64a
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue May 10 20:38:25 2011 +0100

    dri: Flush the batch after a DRI swap/copy event
    
    To minimise lag in those every so critical games, we want to ensure that
    the copy happens as soon as it is received, so we need to flush the
    batch after processing a swap event and before we go to sleep.
    
    References: https://bugs.freedesktop.org/show_bug.cgi?id=37068
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

unless kwin is bypassing GetImage... I doubt that though.

That the window is redrawn correctly still implies to me that is just deferred writes. Anyway if you are in a position to test xf86-video-intel.git, you can quickly confirm whether or not that patch helps.

Created attachment 47658 [details]
screenshot with DDX from git 2011-06-06

Hi Chris,

Looks like the patch you proposed doesn't work, I've built DDX from git yesterday and artifacts still here. Look at new screenshot notice taskbar. BTW I tried to build DDX with brand new SNA engine - and seems it doesn't work, i.e. when I turn on effects in KDE wallpaper disappear and some starge backgraund drawn under panel

SNA requires patches to the xserver as well for correct SHM operation. Thanks for confirming the bug with current master.

Created attachment 53335 [details] [review]
Force synchronous TLB invalidations

This does seem similar to the original TLB invalidation bug, so I wonder if this is an example where we need the workaround.

IMHO the artifacts in those screenshots look very similiar to what I encountered in XBMC (subtitle corruption) and XFCE like I explained in bug #42506.

Compare:
https://bugs.freedesktop.org/attachment.cgi?id=47658
https://bugs.freedesktop.org/attachment.cgi?id=53041

I know that Chris said that #42506 is probably a Mesa problem, but could this be the same problem after all?

I finally managed to compile the kernel with the "Force synchronous TLB invalidations" patch. It didn't compile at first, I had to change

+#define I915_TIMESTAMP_INDEX		0x22

to

+#define I915_GEM_TIMESTAMP_INDEX		0x22

seemed to make sense to me and it compiled successfully. Unfortunately, it didn't fix it for me, I still have the same red artifacts in the subtitles that look very similiar to the ones in Alexanders screenshots.

The other issues I described in bug #42506 are also still there, but I just assume that these are really a Mesa problem.

I'm running kernel 3.1.3 / xf86-video-intel 2.17.0 now btw.

Ok, since then we've replaced the MI_FLUSH with pipecontrol and its w/a. Does that help? Can the issues be reproduced with SNA?

This has been fixed for me since kernel 3.3-rc1, see also bug #42506.

Hmm, could be semaphores, rc6, missed irqs. At any rate be prepared for a reoccurrence...