Created attachment 103760 [details]
glxinfo

"I'm not using a compositing window manager"

contradicts

"8369166349c92a20d9a2e7d0256e63f66fe2682b is the first bad commit"

as that only affects Composite windows.

To confirm your bisect can you try:

diff --git a/src/sna/sna_dri2.c b/src/sna/sna_dri2.c
index 5d1c3da..7734460 100644
--- a/src/sna/sna_dri2.c
+++ b/src/sna/sna_dri2.c
@@ -54,7 +54,7 @@ USE OR OTHER DEALINGS IN THE SOFTWARE.
 #endif
 
 #define DBG_CAN_FLIP 1
-#define DBG_CAN_XCHG 1
+#define DBG_CAN_XCHG 0
 
 #define DBG_FORCE_COPY -1 /* KGEM_BLT or KGEM_3D */

I tried your patch against 2.99.914, it didn't help. 

So I double checked my bisect by doing a git checkout 08148896196443a8582c30b47ff546acca78d69c (that's the commit before the bad one) and then compiling/installing/then running the game, no problems. Then I did a git checkout 8369166349c92a20d9a2e7d0256e63f66fe2682b (that's the first bad commit) and then compiling/installing/then running the game, now is get the random flickering blotches. The bad commit is pretty big, the patch is about 2600 lines:

http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=8369166349c92a20d9a2e7d0256e63f66fe2682b

I wish I had more info to give you, maybe that bad commit could be broken down into smaller pieces that I could patch in to last good commit one at a time and narrow it down for you?

Well, maybe this is a non-problem. I noticed some tearing while running that game. So I enabled TearFree and that fixes the random flickering blotches with 2.99.914. Yahoo!!! I'm one of the developers of Fatdog64, would there be any downside if we enable TearFree by default? I looked at the man page, I'm guessing it's off by default because most folks run a compositing window manager.

Thanks
Kirk

Outside of skipping SwapBuffers if the buffers are stale, there is not much in there (it's mostly taken up by a rename).

Just to rule out a common issue, first try:

diff --git a/src/sna/sna_dri2.c b/src/sna/sna_dri2.c
index 5d1c3da..4d006f8 100644
--- a/src/sna/sna_dri2.c
+++ b/src/sna/sna_dri2.c
@@ -2918,7 +2918,7 @@ sna_dri2_schedule_swap(ClientPtr client, DrawablePtr draw, DRI2BufferPtr front,
 
        if (immediate_swap(sna, *target_msc, divisor, draw, crtc, &current_msc)) {
                bool sync = current_msc < *target_msc;
-               if (!sna_dri2_immediate_blit(sna, info, sync, true))
+               if (!sna_dri2_immediate_blit(sna, info, true, true))
                        sna_dri2_event_free(sna, draw, info);
                *target_msc = current_msc + sync;
                return TRUE;


(which disables adaptive vsync), then try:

diff --git a/src/sna/sna_dri2.c b/src/sna/sna_dri2.c
index 5d1c3da..57cedd6 100644
--- a/src/sna/sna_dri2.c
+++ b/src/sna/sna_dri2.c
@@ -2856,7 +2856,7 @@ sna_dri2_schedule_swap(ClientPtr client, DrawablePtr draw, DRI2BufferPtr front,
                goto skip;
 
        if (get_private(back)->stale)
-               goto skip;
+               ErrorF("rendering with a stale back buffer, client didn't call GetBuffers before SwapBuffers\n");
 
        assert(sna_pixmap_from_drawable(draw)->flush);
 


(In reply to comment #4)
> Well, maybe this is a non-problem. I noticed some tearing while running that
> game. So I enabled TearFree and that fixes the random flickering blotches
> with 2.99.914. Yahoo!!! I'm one of the developers of Fatdog64, would there
> be any downside if we enable TearFree by default? I looked at the man page,
> I'm guessing it's off by default because most folks run a compositing window
> manager.

TearFree offers advantages even with a compositing manager since it enables the single crtc flips (useful for playing games on a single screen in a multimonitor setup). And it should really present any extra overhead in the compositing scenario. The only reason I have left it off for now (it is enabled by default in some powersaving modes) is the worry I have with reserving space for an extra framebuffer in our early (8xx) chipsets.

I tried both patches against 2.99.914, first separately and then together. Sorry, no help. I had to apply the patches manually, which wasn't a problem, tried to apply against git from yesterday as well. If they were supposed to be applied to something different let me know.

>TearFree offers advantages even with a compositing manager since it enables the >single crtc flips (useful for playing games on a single screen in a multimonitor >setup). And it should really present any extra overhead in the compositing >scenario. The only reason I have left it off for now (it is enabled by default >in some powersaving modes) is the worry I have with reserving space for an extra >framebuffer in our early (8xx) chipsets.

Great, I don't think the older chipsets should be a worry for us.

(In reply to comment #6)
> I tried both patches against 2.99.914, first separately and then together.
> Sorry, no help. I had to apply the patches manually, which wasn't a problem,
> tried to apply against git from yesterday as well. If they were supposed to
> be applied to something different let me know.

No, that would just be whitespace from pasting them into bugzilla. Hmm, the second patch would only add extra logging if it was hit - did you check for extra output in Xorg.0.log?

>did you check for extra output in Xorg.0.log?

Nothing new logged after running the game.

I thought that tearfree had solved all my problems, but I found another. 
When using ffDiaporama (Video editor), if you add a video slide, then click on that slide to edit, then watch the preview of that video slide, it flickers and jumps. That's on .914 with or without tearfree. If I roll back to .911 no problem. Like the video game ffDiaporama uses SDL-1.2 for video preview. I also did the same test on an older laptop with Ironlake and had the same results.

If you see an application tearing with TearFree, you know that the application is at fault (doing partial rendering into its frontbuffer).

Sorry for the bad info, you're correct. I thought I had tearfree disabled but I forgot that I had our build chain set to enable it with autoconf. Probably have to stick with .911 until we can upgrade ffDiaporama since tearfree is required for anything later.

Hmm, installed at ffDiaporama. Added a video file, hit the play button below. Nothing untoward happens here with ffdiaporama 1.5-2build1 (and using the mutter based gala window manager). Are you positive you have no compositor enabled?

Actually I just tried the .911 driver with tearfree enabled, and disabled
it had no problems. The .914 driver only has a problem with tearfree
enabled, if it's disabled then it's fine. I knew I had test it both ways,
but I must have only did that with .911.

>Hmm, installed at ffDiaporama. Added a video file, hit the play button
below. Nothing untoward happens here with ffdiaporama 1.5-2build1

We're using ffDiaporama-2.1. The last video I tested with was this small
one here:
http://puppylinux.com/test/media-test-video/lionhugsandkisseswoman.wmv

To reproduce the problem do this:

1) OPen ffDiaporama, click on the "Project" tab and then "Add files" to add
a file.
2) After adding  a file double click on the slide to bring up the "Slide
Properties" window.
3) In the Slide Properties window click on "Edit Block" and select
"Correct, reframe or cut video"

Then you'll see the problem. The preview on the main screen doesn't show
it.  And apparently it's only a problem with .914 and tearfree enabled.

>Are you positive you have no compositor enabled?

I'll double check with the guy I work with that he didn't do something
crazy like patch one into openbox. Looking at ps -e I don't see one and I
recognize everything there.



On Mon, Sep 1, 2014 at 9:26 AM, <bugzilla-daemon@freedesktop.org> wrote:

>   *Comment # 12 <https://bugs.freedesktop.org/show_bug.cgi?id=81973#c12>
> on bug 81973 <https://bugs.freedesktop.org/show_bug.cgi?id=81973> from
> Chris Wilson <chris@chris-wilson.co.uk> *
>
> Hmm, installed at ffDiaporama. Added a video file, hit the play button below.
> Nothing untoward happens here with ffdiaporama 1.5-2build1 (and using the
> mutter based gala window manager). Are you positive you have no compositor
> enabled?
>
>  ------------------------------
> You are receiving this mail because:
>
>    - You reported the bug.
>
>

I checked to see if first bad/last good commit from my previous bisect still applied to this problem and it does not. I guess I should have opened a new bug. Anyway I did another bisect and it gives me this:

# git bisect good
49e72bd4e59085aa940e5af63381c5394ee670ad is the first bad commit
commit 49e72bd4e59085aa940e5af63381c5394ee670ad
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Apr 15 11:24:10 2014 +0100

    sna: Discard TearFree readback when overdrawing
    
    References: https://bugs.freedesktop.org/show_bug.cgi?id=77436
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

:040000 040000 26d635f471981c81ebacb252b1d4593e73094923 ed01b4b2fe76e4eb0e2912fe4ce264b061e8cf47 M	src
# 

I couldn't revert that patch, but I could switch to UXA which does fix the problem for .914 with or without TearFree. UXA also fixes the problem I had with the game, with or without TearFree. I thought I had tested that before, guess I messed that up. For a Linux distribution should UXA be the default? Or is SNA needed for the newer chip sets?

SNA is the default for the reason like above it has more features and supports more chipsets... For UXA, TearFree rendering is not even an option.

>Are you positive you have no compositor enabled?

Yes, no compositor. 

If you're interested you can see what I'm seeing by installing Fatdog64-700alpha1. The ISO is about 250mb, real easy to install. The whole OS is just two files, the kernel and a initrd, we use a layered filesystem (aufs). 

To install:

Download the iso here: http://distro.ibiblio.org/fatdog/iso/

Make a folder on the root of an ext2/3/4 partition , maybe call it 700a. 

Copy vmlinuz and initrd from the ISO to 700a.

Inside the 700a folder create another folder named fd64save (This will be the R/W branch of the filesystem.)

Add a grub entry: (assuming sda2 for your partition)

title Fatdog64-700a
  rootnoverify (hd0,1)
  kernel /700a/vmlinuz savefile=direct:device:sda2:/700a/fd64save
  initrd /700a/initrd

Then just boot into it. Lots of other ways to boot, but this is easy assuming you have ext partition.
 
That comes with the .911 driver, I've uploaded the .914 driver compiled with TearFree enabled by default here: http://distro.ibiblio.org/fatdog/broken/xf86-video-intel-2.99.914-x86_64-1.txz  Just download, then right-click on it and select install. Ffdiaporama is under Multimedia on the main menu, follow the steps in my previous post on how to duplicate the problem.

If you want to be able to compile, all of our development files (except QT) are in one file fd64-devx_700a1.sfs (actually a compressed filesystem) that can be found here: http://distro.ibiblio.org/fatdog/sfs/700/ Download and put it in the root for the partition that you used before. Then open a terminal and type load_sfs.sh. That script will let you add the development files to the filesystem.

commit aa10f480c566b8523cdd49b3e23f64b7b9625987
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Sep 3 10:24:19 2014 +0100

    sna: Drop false IGNORE_DAMAGE hint
    
    IGNORE_DAMAGE is used by sna_drawable_use_bo to ignore both CPU/GPU
    damage. It used to only ignore CPU damage, but now is a more general
    hint. However, here we were intending to only say ignore the cpu damage
    that we explicitly discarded anyway.
    
    References: https://bugs.freedesktop.org/show_bug.cgi?id=81973
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>


That fixes ffDiaporama in your example. Thanks.

(In reply to comment #17)
> commit aa10f480c566b8523cdd49b3e23f64b7b9625987
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Wed Sep 3 10:24:19 2014 +0100
> 
>     sna: Drop false IGNORE_DAMAGE hint

Sorry for intervening. But i believe this commit is responsible for occasional flickering of kde4 drop down menus.

>That fixes ffDiaporama in your example. Thanks.

Indeed it does. Thank you! 

I was hoping it would also solve the problem with UrbanTerror-4.2 flickering without TearFree enabled, but it doesn't. We're going to go with TearFree enabled by default, so good enough. I used to look for ATI GPUs when shopping for a laptop, but now Intel's open source drivers are much better and usually cheaper too. 

Thanks again,

Kirk

So I wonder if urbanterror uses SDL which with recent Xorg will try to use a backing store for GL surfaces (which flickers). Do you know?

>So I wonder if urbanterror uses SDL which with recent Xorg will try to use a >backing store for GL surfaces (which flickers). Do you know?

Yes it does use SDL-1.2. It's a Quake3 (ioquake3) engine game. For whatever reason though it doesn't flicker with the .911 driver.

I have an older laptop with Ironlake graphics so I tried Urban Terror on it. With TearFree on it has some flickering blotches from time to time, not a lot. With TearFree off, it's very bad. Installed the .911 driver and even with TearFree off there's no problems, well except some tearing.

If you want to try it, the game is here:

http://www.urbanterror.info/downloads/

UrbanTerror42_full018  (1625MB)

Also, we've upgraded to:

Linux-3.16.2
Mesa-10.2.7
xf86-video-intel-2.99.916

When does the flickering start? Hmm, I guess I have switch over to your install again.

With TearFree disabled, you'll see it most of the time when you're playing the game. With Tearfree enabled I didn't see it on my Ivy Bridge laptop, but I did see it sometimes on the older Ironlake laptop. Maybe it's worse on the Ironlake laptop just because it's slower and the screen resolution is a little higher too.

I have this problem too. I am using Gentoo.
I have noticed this flickering on the following versions of xf86-video-intel:
2.99.916, 2.99.914
On 2.99.911-r1 it does not exist.

I encountered this problem in 2 programs/games:
1. popcorn-time (https://popcorntime.io/)
It's reproducible on my machine every time. How to do that:
Maximize window, choose any film or tv episode, press "watch now". Now move the mouse cursor between the top and bottom edges of the screen - you will notice the shadows on those edges flickering.
Now press "fullscreen" button in the bottom-right of the window and wait till the shadows on screen edges disappear. When that happens, FPS of the video will decrease significantly and the video will be laggy and stuttering. These lags don't appear on versions of xf86-video-intel on which flickering does not appear so I believe they are connected.

1. SteamWorld Dig
It's a game available in steam, humble indie bundle and gog (or you can download it on torrents).
How to see the flickering:
Run the game in fullscreen (use alt+enter to switch, this is important - flickering does not appear in windowed mode), now just move mouse around in menu or you can even start the game and press escape to go to pause menu - you'll notice HUD (pause menu, main menu buttons) flickering.


Here is some info about my system and about the package:

=================================================================
                        Package Settings
=================================================================

x11-drivers/xf86-video-intel-2.99.916 was built with the following:
USE="dri sna udev -debug -glamor -uxa -xvmc" ABI_X86="64"
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-z,lazy"


$ lspci -vnn | ack -A9 -i VGA
00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller])
        Subsystem: ASUSTeK Computer Inc. Zenbook Prime UX31A [1043:1517]
        Flags: bus master, fast devsel, latency 0, IRQ 40
        Memory at f7800000 (64-bit, non-prefetchable) [size=4M]
        Memory at e0000000 (64-bit, prefetchable) [size=256M]
        I/O ports at f000 [size=64]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: <access denied>
        Kernel driver in use: i915



Tell me if you need any more info or something else.

The other report I have seen is https://bugs.archlinux.org/task/40900?project=1&cat[0]=2&string=xf86-video-intel which narrows it down to the use of the BackingStore. The only problem I have is that iirc the BackingStore would have been available forever (certainly in 2.99.911) and it will always cause flickering (as the internal copy in X from the backing store to the frontbuffer has never been synchronized).

If you could confirm that is was the "SDL-backingstore" option that was causing the flickering, at least that only means I have one bug to worry about.

I built libsdl-1.12.15 using Arch's patches here: https://aur.archlinux.org/packages/sdl-nobackingstore/

That does fix the flickering with Urban Terror on .916, and that's with TearFree disabled. With TearFree enabled there's no flickering and no tearing :).

It looks like xf86-video-intel-2.99.912 and newer just exposes a bug in SDL/Xorg-server. I'll double check tonight on my old Ironlake laptop where the problem was much worse, but I think that's it.

Went home for lunch and tried the patched SDL on my Ironlake laptop, that does fix it. So sorry for running you around Chris. Looks like a Xorg-server bug and since SDL pretends that bug doesn't exist, it's kind of an SDL bug. For some reason .912 and later just exposes it. This bug can be closed as far as I'm concerned.