Forgot to mention, the problem only manifests with SNA, with UXA window movement is smooth without tearing.

I suspect the tearing is a perception issue, as the front buffer rendering of an uncomposited X server is unchanged. However, a delay is built into sna to avoid flushing the batch on every block handler and there I have erred on the side of slow updates during periods of small changes.

I've added an option to disable the deferred update mechanism entirely,
  Option "DelayedFlush" "False",
but you can also play with

diff --git a/src/sna/sna_accel.c b/src/sna/sna_accel.c
index f6095b5..6a6c841 100644
--- a/src/sna/sna_accel.c
+++ b/src/sna/sna_accel.c
@@ -6008,9 +6008,9 @@ static Bool sna_accel_do_flush(struct sna *sna)
        to.it_value.tv_sec = 0;
        to.it_value.tv_nsec = 10 * 1000 * 1000;
 
-       /* Then periodic updates at 25Hz.*/
+       /* Then periodic updates at 100Hz.*/
        to.it_interval.tv_sec = 0;
-       to.it_interval.tv_nsec = 40 * 1000 * 1000;
+       to.it_interval.tv_nsec = 10 * 1000 * 1000;
        timerfd_settime(sna->timer[FLUSH_TIMER], 0, &to, NULL);
 
        sna->timer_active |= 1 << FLUSH_TIMER;

to see if there is a better value which works for you. I plucked a figure that was half my monitor's refresh rate, which I think is an acceptable compromise - maybe I should make that an automatic selection...

Thanks for the fast response.

I can confirm that the issue disappears when adjusting the timer to 100Hz :)
Probably the 40Hz bite a bit with my laptop's refresh rate of 60Hz - maybe 2x refresh rate wouldn't be a bad idea?

Thanks, Clemens

I've tweaked the flush interval to be set to twice the vblank. Can you please experiment and see if that is acceptable, might need to go to vblank or half-vblank. :|

Hi,

Does the current code set it to half-vblank? Because with the automatic adoption I don't see an improvement - whereas setting it to 100Hz makes everything smooth again. 
Why is it so important to keep flush frequency so low - power consumption?

Thanks, Clemens

Unmeasured yet, but the goal is indeed to reduce the number of unnecessary wakeups and improve power consumption and throughput at the cost of latency -- which is meant to still be around the one or two vblank mark and supposedly unnoticeable. ;-)

I'm curious as to what the actual update rates are and so I'll get around to adding some low impact debugging to measure them and see if I can find a reason why it is so noticeable for you. One starting point would be to use
  trace-cmd record -e i915
which we give me a timeline of all events and that way I can work out the frequency that the ddx is submitting batches.

(In reply to comment #5)
> Does the current code set it to half-vblank?

Currently two-vblank.

diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index a82ccd8..dacf7bf 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -601,7 +601,7 @@ static void update_flush_interval(struct sna *sna)
        if (max_vrefresh == 0)
                max_vrefresh = 40;
 
-       sna->flush_interval = 2000 * 1000 * 1000 / max_vrefresh;
+       sna->flush_interval = 1000 * 1000 * 1000 / max_vrefresh;
        DBG(("max_vrefresh=%d, flush_interval=%d ns\n",
               max_vrefresh, sna->flush_interval));
 }

would set it to be vblank (16ms, I guess in your case)

Thanks, setting it to vblank seems to do the trick :)

If you can find a moment to test current tip of sna, I'm interested to see if you can notice any change in the default behaviour. Thanks.

the perceived behaviour with default settings is unchanged unfourtunatly.

I pushed the patch to flush the batch at least once for each vblank. Can you please confirm happiness? :)

Hapiness confirmed :)

commit 676cb4e38dc381b2ef4fb092b66db80687aa5013
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Nov 4 23:30:09 2011 +0000

    sna: Run the deferred flush at vrefresh
    
    This helps to reduce the perceived jerkiness of the redraw.
    
    Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42413
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Let me know if you find any other areas that can be improved. Many thanks!

just stumbled over a video which has tearing issues with SNA, whereas playback is fine with UXA (using mplayer + XV backend).

I'll do some testing with delayed flushing disabled to see if it makes a difference.

vsync'ed video is emitted asap, irrespective of delayed flushing. Are you sure it should be vsync'ed? The debug=full Xorg.log will have the entire batch for you to verify that the wait-for-scanlines is being emitted... After which it is not my fault! ;-)