Bug 81973

Summary: xf86-video-intel-2.99.912 and newer causing flickering on game.
Product: xorg Reporter: kirk <kirkpuppy>
Component: Driver/intelAssignee: Chris Wilson <chris>
Status: RESOLVED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: normal    
Priority: medium CC: absorbb
Version: git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
URL: https://bugs.archlinux.org/task/40900?project=1&cat[0]=2&string=xf86-video-intel
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg Log
none
glxinfo none

Description kirk 2014-07-31 17:24:00 UTC
Created attachment 103759 [details]
Xorg Log

Hi,

With anything newer than xf86-video-intel-2.99.911 including today's git, I get random flickering on parts of the screen while playing Urban_Terror-4.2. I've tried using glamor, sna, and uxa, no difference. I bisected it to this commit:

# git bisect bad
8369166349c92a20d9a2e7d0256e63f66fe2682b is the first bad commit
commit 8369166349c92a20d9a2e7d0256e63f66fe2682b
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Jun 4 08:29:51 2014 +0100

    sna/dri2: Enable immediate buffer exchanges
    
    The primary benefit of this is avoid the extra blit when using a
    compositor and instead propagate the compositor flip on the frontbuffer
    to the scanout, or equivalently allows a fullscreen game to flip onto
    the scanout without intervention by TearFree.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

:040000 040000 dfbc6f4995687fd29ebe5072c432fc951449c977 22f8ea8ed349d4ce0e37115a5aa24856321857e0 M	src
# 

I'm using the following:

i5-3340m
Linux-3.15.5
Mesa-10.2.4
Xorg-server-1.15.2

I'm not using a compositing window manager. I'm using Openbox or JWM.

I configured with:

# ./configure --prefix=/usr --libdir=/usr/lib64 --enable-kms-only --with-default-accel=sna --enable-glamor
Comment 1 kirk 2014-07-31 17:24:45 UTC
Created attachment 103760 [details]
glxinfo
Comment 2 Chris Wilson 2014-07-31 17:29:57 UTC
"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 */
Comment 3 kirk 2014-07-31 22:22:42 UTC
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?
Comment 4 kirk 2014-07-31 22:55:46 UTC
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
Comment 5 Chris Wilson 2014-08-01 06:40:49 UTC
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.
Comment 6 kirk 2014-08-01 13:23:59 UTC
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.
Comment 7 Chris Wilson 2014-08-01 13:44:17 UTC
(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?
Comment 8 kirk 2014-08-01 19:02:03 UTC
>did you check for extra output in Xorg.0.log?

Nothing new logged after running the game.
Comment 9 kirk 2014-08-31 23:35:12 UTC
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.
Comment 10 Chris Wilson 2014-09-01 06:07:42 UTC
If you see an application tearing with TearFree, you know that the application is at fault (doing partial rendering into its frontbuffer).
Comment 11 kirk 2014-09-01 13:19:26 UTC
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.
Comment 12 Chris Wilson 2014-09-01 13:26:32 UTC
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?
Comment 13 kirk 2014-09-01 13:58:56 UTC
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.
>
>
Comment 14 kirk 2014-09-02 00:35:52 UTC
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?
Comment 15 Chris Wilson 2014-09-02 05:27:08 UTC
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.
Comment 16 kirk 2014-09-02 23:30:20 UTC
>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.
Comment 17 Chris Wilson 2014-09-03 09:27:02 UTC
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.
Comment 18 Ildar Nurislamov 2014-09-03 12:01:31 UTC
(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.
Comment 19 kirk 2014-09-03 16:43:36 UTC
>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
Comment 20 Chris Wilson 2014-09-09 07:07:06 UTC
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?
Comment 21 kirk 2014-09-09 18:07:49 UTC
>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.
Comment 22 kirk 2014-09-10 02:54:43 UTC
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)
Comment 23 kirk 2014-09-10 02:57:30 UTC
Also, we've upgraded to:

Linux-3.16.2
Mesa-10.2.7
xf86-video-intel-2.99.916
Comment 24 Chris Wilson 2014-09-10 08:24:48 UTC
When does the flickering start? Hmm, I guess I have switch over to your install again.
Comment 25 kirk 2014-09-10 11:05:02 UTC
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.
Comment 26 headcrabextra 2014-09-12 05:14:41 UTC
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.
Comment 27 Chris Wilson 2014-09-12 10:59:29 UTC
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.
Comment 28 kirk 2014-09-12 13:43:37 UTC
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.
Comment 29 kirk 2014-09-12 16:11:38 UTC
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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.