Bug 91036

Created attachment 116606 [details]
xorg log (I didn't enable Tearing in this one)

Created attachment 116607 [details]
dmesg

Created attachment 116608 [details]
glxgears -info

Created attachment 116609 [details]
glxinfo

Created attachment 116610 [details]
kernel version

Created attachment 116611 [details]
xorg conf

I can't use print screen (don't know why) but if I run glxgears and maximize it, it shows the gears and green frames over gears (as if the green gear frame didn't update). If I run directly fullscreen, gears behave fine. With browser I have same issues than with terminal.

Created attachment 116612 [details]
xorg log with tearing option enabled

If I use "AccelMethod" "sna" instead of glamor I get bugs also

Created attachment 116613 [details]
lspci -vvnn

You don't have DRI3 or glamor in your ddx. Saying it doesn't happen with Option "AccelMethod" "glamor" is dubious. Start from the beginning again, and describe what compositing/window manager you are using, the examples that fail, and provide logs for broken and working sessions.

If you can build xf86-video-intel.git for yourself that is one less variable for me to worry about:

$ sudo apt-get build-dep xserver-xorg-video-intel
$ git clone git://anongit.freedesktop.org/xorg/driver/xf86-video-intel
$ cd xf86-video-intel
$ ./autogen.sh --prefix=/usr --enable-debug=pixmap
$ make -j10 && sudo make install

Sorry, I think you misunderstood me. It happens with both options, so if I don't have glamor it means that is with sna. However, as I have read in X log, when trying to load DRI3 fails, so it returns to DRI2. Then I'm using DRI2. X seems to load glamor and doesn't complain about not having access to it, but I suppose i'm worng. I'm going to compile the driver and check output.

(In reply to 19.jaime.91 from comment #9)
> If I use "AccelMethod" "sna" instead of glamor I get bugs also

Ah, I misinterpreted this to mean glamor solved the bug and so I was puzzled (since I assumed that you would have used the default options first before enabling something like glamor).

Please do compile the ddx with the extra debugging and see if that catches an issue.

I'm trying to compile it, but I'm using ubuntu with xorg-edgers and oibaf ppas and I get a dependency mess.

Ok, i have seen that i can install debuggin simbols for the driver. I have packages:
xserver-xorg-video-intel and xserver-xorg-video-intel-dbg
version git 15-06-19
It's enough if I install it?

Created attachment 116621 [details]
Info

Created attachment 116622 [details]
Info using compiled driver

I have compiled the driver with pixman debuggin option. I get this info. Also, with TearFree option enabled, when I loggin in dm X breaks.

Created attachment 116623 [details]
dmesg with pixman debuggin option

I don't know if I have to use gdb for debug X, if so how do I do it?

Created attachment 116624 [details]
gdb output

Created attachment 116631 [details]
That's what I see

I have upgraded ubuntu to 15.04 and I don't have the problem with the browser or with glxgears, so perhaps it was a problem of Xorg? (I was using 1.15 and now 1.17)

I'm also having tearfree problems. Please advise if I should include this as a separate bug report. 

My system is:
Mobile Ivy Bridge 
Debian sid
xf86-video-intel=master
linux=4.0.5 or drm_intel master (tried both)
xserver-xorg-core=2:1.17.1-2
xserver-xorg=1:7.7+9

For me, the problem only seems to be when I have an extended desktop (non-mirrored) second display connected via HDMI1 together with my laptops LVDS1. I set this up with

    xrandr --output LVDS1 --mode 1920x1080 --rate 60  --output HDMI1 --mode 1920x1080 --rate 23.98 --set "Broadcast RGB" "Full" --right-of LVDS1
(my LVDS1 is unfortunately restricted to 60hz or 50hz)

My test case is running

    mpv --no-config --vo=opengl 23.80fps.mkv
(http://mpv.io/)

in fullscreen on the HDMI display. This works nearly flawlessly with the old UXA acceleration mode aside from the occasional judder/dropped frame.

With base no xorg configuration (i.e., base SNA), I get bad video tearing. Therefore, I enable the tearfree option. In this case, it seems to work ok on either screen in windowed mode, but when I fullscreen to the HDMI1 display, the video freezes or goes black. The player itself, including audio, appears to continue going reporting no dropped frames, although it does fill the terminal with a bunch of

[vo/opengl/x11] X11 error: BadDrawable (invalid Pixmap or Window parameter)

This persists even if I then exit fullscreen and go back to windowed mode. I have to stop and restart the player in windowed mode to resume normal operation.

Then I tried the above with the HDMI1 display also set to the same 60hz refresh rate as the LVDS1 (not ideal for video playback)

    xrandr --output LVDS1 --mode 1920x1080 --rate 60  --output HDMI1 --mode 1920x1080 --rate 60 --set "Broadcast RGB" "Full" --right-of LVDS1

In this case, it behaves a little better. No X11 errors or freezing with fullscreen HDMI1, but frequently (about every 10s or so) one or more frames from within the last second are displayed resulting in a jerky back-and-forth video playback. Again the mpv player itself continues to run without reporting dropped frames and the audio is uninterrupted. In this case, I also observe similar corruption as described by the original reporter.

So far, I have yet to experience these problems if I mirror the displays (even with different refresh rates)
    xrandr --output LVDS1 --mode 1920x1080 --rate 60  --output HDMI1 --mode 1920x1080 --rate 23.98 --set "Broadcast RGB" "Full" --same-as LVDS1

Same refresh rate mirrored also works well
    xrandr --output LVDS1 --mode 1920x1080 --rate 60  --output HDMI1 --mode 1920x1080 --rate 60 --set "Broadcast RGB" "Full" --same-as LVDS1

Finally, turning off the LVDS1 entirely seems to work
    xrandr --output LVDS1 --off --output HDMI1 --mode 1920x1080 --rate 23.98 --set "Broadcast RGB" "Full" --same-as LVDS1

(In reply to Kevin Mitchell from comment #23)
> I'm also having tearfree problems. Please advise if I should include this as
> a separate bug report. 
> 
> My system is:
> Mobile Ivy Bridge 
> Debian sid
> xf86-video-intel=master
> linux=4.0.5 or drm_intel master (tried both)
> xserver-xorg-core=2:1.17.1-2
> xserver-xorg=1:7.7+9
> 
> For me, the problem only seems to be when I have an extended desktop
> (non-mirrored) second display connected via HDMI1 together with my laptops
> LVDS1. I set this up with
> 
>     xrandr --output LVDS1 --mode 1920x1080 --rate 60  --output HDMI1 --mode
> 1920x1080 --rate 23.98 --set "Broadcast RGB" "Full" --right-of LVDS1
> (my LVDS1 is unfortunately restricted to 60hz or 50hz)
> 
> My test case is running
> 
>     mpv --no-config --vo=opengl 23.80fps.mkv
> (http://mpv.io/)
> 
> in fullscreen on the HDMI display. This works nearly flawlessly with the old
> UXA acceleration mode aside from the occasional judder/dropped frame.
> 
> With base no xorg configuration (i.e., base SNA), I get bad video tearing.

Tearing is expected if either the application requests tearing, or is too slow to maintain the requested framerate (i.e. if it misses a frame, the next frame is presented as soon as possible without synchronisation, the technique is called adaptive vsync and is meant to help reduce jitter).

> Therefore, I enable the tearfree option. In this case, it seems to work ok
> on either screen in windowed mode, but when I fullscreen to the HDMI1
> display, the video freezes or goes black. The player itself, including
> audio, appears to continue going reporting no dropped frames, although it
> does fill the terminal with a bunch of
> 
> [vo/opengl/x11] X11 error: BadDrawable (invalid Pixmap or Window parameter)

That's a distinct bug, it's generated by the core layer. There is one known issue involving DRI2/DRI3 interop in mpv that generates that error, bug 85665.

Ultimately I need to have a look at your Xorg.0.log to see which class of errors you are likely seeing.

With "AccelMethod" "uxa" I don't have any problem, also.

> Tearing is expected if either the application requests tearing, or is too
> slow to maintain the requested framerate (i.e. if it misses a frame, the
> next frame is presented as soon as possible without synchronisation, the
> technique is called adaptive vsync and is meant to help reduce jitter).

Is there a way for the application to know programmatically when this happens?

> > [vo/opengl/x11] X11 error: BadDrawable (invalid Pixmap or Window parameter)
> 
> That's a distinct bug, it's generated by the core layer. There is one known
> issue involving DRI2/DRI3 interop in mpv that generates that error, bug
> 85665.

I've just updated that one. I'm no longer seeing that problem likely as the result of a kernel or xserver update. 
That was also vaapi hardware-decoding specific, whereas the above described tests have hardware decoding disabled.

> Ultimately I need to have a look at your Xorg.0.log to see which class of
> errors you are likely seeing.

standby will post later tonight. So I should open a separate bug for this?

Ok, I'm having the issue without TearFree option. So its a problem of sna.

Please recap which issue you are seeing.

Now I have the same issue with everything but uxa. Its not a big deal now. Redimension of glxgears brings strange stuff to the screen.

https://drive.google.com/file/d/0B4aVP07hgDk6eWxydkFRN3ZoUWs/view?usp=sharing

Ah the danger of triple buffering Windows.

commit e5c6e48cc9e11f659d0d9d1b907357e28a554e9f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Jun 28 18:25:37 2015 +0100

    sna/dri2: Discard backbuffer cache on Window resize
    
    After the Window resizes, we should never hand back a buffer of the old
    size or else we end up rendering garbage - with the possibilty of GPU
    hangs or memory corruption.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91036
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Everything works fine now. Thank you!

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

Unfortunately, I'm still having this or very similar issue recently, with or w/o TearFree. Especially when using mpv and Google Chrome at the same time. Nothing in the logs. dmesg also clear when driver compiled with --enable-debug=pixmap

Screencast: https://youtu.be/OJyaVGTVgkk

Arch Linux
-------------
Linux 4.1.2
driver: 2.99.917.377.g2c50639
xorg server: 1.17.2
mesa: 10.6.2
gnome: 3.16.2

mpv config
vo: opengl
hwdec: vaapi

Forgot to mention hardware. It's SB HD3000. Bisected to [fc137ae504b31a238e64bc1a5d19c41b2074c60a] sna/dri2: Avoid touching shared gpu_bo->flush between dri2/dri3

Noticed, that it's 100% reproducible when mpv is playing 60fps videos. Sample (630KB): https://www.dropbox.com/s/q8sbhy98mpxz0du/60fps.mkv?dl=0

Please, let me known if this is a different issue, and I should fill a new bug report.

Best regards.