Using MESA_copy_subbuffer? Tearing is to be expected since it is not specified to be tear-free. Only if the application uses swapbuffers will it be tearfree.

For starters, I need Xorg.0.log, xorg.conf, and glxinfo. And for 945gm you should find the xv backend more performant and power efficient.

Created attachment 90282 [details]
glxinfo

Created attachment 90283 [details]
Xorg.0.log

No explicit xorg.conf.

(In reply to comment #2)
> And for 945gm you should find the xv backend more performant and
> power efficient.

Will try xv the next time I hit extreme tearing and check the difference.

I also need to check whether you are using a compositing manager, which also affects whether vsync is performed.

(In reply to comment #7)
> I also need to check whether you are using a compositing manager, which also
> affects whether vsync is performed.

No compositing manager - just a minimal window manager.

(In reply to comment #6)
> (In reply to comment #2)
> > And for 945gm you should find the xv backend more performant and
> > power efficient.
> 
> Will try xv the next time I hit extreme tearing and check the difference.

I did try it when I saw tearing in a 720p video and using xv seems to have fixed it but tearing itself is sometimes subtle and sometimes hard to ignore.

There is a good test case included with xf86-video-intel, test/tearing.mp4 (and test/mkvsync.sh) which should highlight tearing.

Given all of the above, both UXA and SNA implement vsync in the same fashion on gen3.

(In reply to comment #10)
> There is a good test case included with xf86-video-intel, test/tearing.mp4
> (and test/mkvsync.sh) which should highlight tearing.

Will have a look tomorrow.

> Given all of the above, both UXA and SNA implement vsync in the same fashion
> on gen3.

Am I using vsync without knowing or is that just stating the outcome of
your analysis?

Does "Tear free" disabled mean the driver didn't enable that feature and it's not something I could or should enable?

TearFree is a driver option to redirect rendering onto a backbuffer and pageflip, like a compositing manager.

VSync is the mechanism the driver uses to prevent the GPU from rendering onto the frontbuffer whilst the display is scanning out from the target area - it prevents tearing within a window. For a fullscreen swapbuffer, we would use a pageflip instead. Hmm, actually if the application is too slow and misses its requested frame, the driver applies "Adapative VSync" and blits the update onto the scanout unsynchronised to the vertical refresh (in order to allow the application to catch up with its timeline).

So the vsync you're talking about is not one you usually enable manually in a game or similar to avoid glitches but is one that is built-in and always enabled in the driver?

It is the one and the same. It is one of the mechanisms (vsync and pageflipping) that the driver uses to implement SwapBuffers that the games use.

Makes sense.

I remembered why I was using opengl-old backend. xv backend causes a slim right border of random colored pixels distracting from the video in full screen. No such issues in x11 backend but you suggested I use xv backend on this gpu.

(In reply to comment #10)
> There is a good test case included with xf86-video-intel, test/tearing.mp4
> (and test/mkvsync.sh) which should highlight tearing.
> 
> Given all of the above, both UXA and SNA implement vsync in the same fashion
> on gen3.

test/tearing.mp4 tears extremely in the lower third of the white bars when using mpv's x11 video out driver. xv and opengl-old mpv video out drivers look the same without such tearing to me but it's still hard on the eyes to watch and follow that big white bar move around. also I tried again and with xv backend that vertical line or border on the right of videos in mpv looks green most of the time. Chris do you need other information?

actually if I run mpv -vo opengl-old or mpv -vo x11 viewing tearing.mp4 both tear 1 out of 3 times in similar ways. running the same with the xv backend doesn't cause tearing. next I'll try UXA. and yeah it's ONE white bar not TWO.

If I force UXA then only mpv -vo x11 shows tearing and the green right border in full screen of mpv -vo xv doesn't show up at all in my limited tests. Is this useful information for improving/fixing SNA?

Tests were too limited and I finally made UXA and mpv -vo xv draw the green right border in a fullscreen video.

The green bar on the right is mpv overallocating the XvImage and fill with 0 (which is green in the YUV colorspace) rather than padding. Those zeroes are then sampled by the hardware if we need to do any form of interpolation, causing it to seep into the output video.

To recap, are you happy that the output is indeed tear free? It sounds like the tests are passing with Xv.

(In reply to comment #22)
> The green bar on the right is mpv overallocating the XvImage and fill with 0
> (which is green in the YUV colorspace) rather than padding. Those zeroes are
> then sampled by the hardware if we need to do any form of interpolation,
> causing it to seep into the output video.

Can that be fixed or turned off. It only happens when the video width
is less than the screen width and it's not always clear green but random
and could be related to the video.

> To recap, are you happy that the output is indeed tear free? It sounds like
> the tests are passing with Xv.

I'm not entirely happy because it's not completely smooth but mpv in
SNA Xv mode is much smoother. If we can get rid of the green bar Xv
seems the best option of the three.

Speaking of tear and smoothness I was considering getting a new display
like Eizo Foris FG2421 that runs at 120Hz or 240Hz. Would that work
with 945gm or does that work at all with Xorg and xf86-video-intel?
Should I ask this on the list instead?

With xorg-server-1.18, intel driver from git at date 20160224 and mpv-0.16.0, with DRI3 enabled:

- I still suffer tearing if not using -vo=xv, with that one it's ok, but with any other -vo option I get tearing with any file and, also, tearing.mp4 test file :/

Manually enabling TearFree solves the problem but, wasn't it supposed to be unneeded with dri3? Also, why is not the option enabled automatically then? (at least for devices needing it)

Thanks :)

*** This bug has been marked as a duplicate of bug 93679 ***