Bug 107421 - [HSW][bisected] "sna: Defer submission of the next shadow frame until halfway through" causes stuttering
Summary: [HSW][bisected] "sna: Defer submission of the next shadow frame until halfway...
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-07-29 16:55 UTC by Thomas Lindroth
Modified: 2019-11-27 13:49 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments
Xorg.log (33.26 KB, text/plain)
2018-07-29 17:17 UTC, Thomas Lindroth 		no flags Details
View All

Description Thomas Lindroth 2018-07-29 16:55:51 UTC 
Hardware: Haswell i7-4790K IGPU using all 3 connectors. All 3 monitors run at 1920x1200@59.95hz

Software: kernel-4.14.59, xorg-server-1.19.5, xf86-video-intel-git (AccelMethod=sna, TearFree=on), mesa-17.3.9, xfce-4.12 without compositing.

commit af36a4ab78cc0e2a85fa40d442bfb92df75dd217
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Apr 1 13:13:19 2018 +0100

    sna: Defer submission of the next shadow frame until halfway through

    Do not immediately post the next shadow flip on completion of the
    current flips, but instead queue a timer for half way through the next
    vblank so that try to we keep the additional input-output lag to less
    than a frame.

After commit af36a4ab78cc0e2a85fa40d442bfb92df75dd217 I've been getting a lot of stuttering when playing video. Both mpv and glxgears stutters. By stutter I mean dropped and duplicated frames.

The stutter only happens when multiple heads are active. Either clone mode or side by side. The stutter is periodic. It happens every 20 sec and last for about 5 sec. The remaining 15 sec is smooth. My guess is that I just ended up with those times on my system by accident. A side effect of my framerate and how fast the framerate drifts between my monitors or something like that.

I assumed the problem was in kernel space first and while debugging I noticed that the tracepoint i915:intel_engine_notify ring=0 fires a lot during stuttering but not when playback is smooth. notify_ring() is part of the irq handler so the RCS engine sends interrupts during stutter but not otherwise. I don't know what that means. The commit before the bad commit have no periodic stutter but the RCS engine sends interrupts almost constantly instead.

Let me know if you need any special debug output.
Comment 1 Thomas Lindroth 2018-07-29 17:17:04 UTC 
Created attachment 140877 [details]
Xorg.log
Comment 2 Chris Wilson 2018-07-29 18:36:54 UTC 
So you haven't tried

commit ac7a4bf44c68c5f323375974b208d4530fb5b60f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Apr 15 15:40:03 2018 +0100

    os/WaitFor: Check timers on every iteration
    
    Currently we only check timer expiry if there are no client fd (or
    other input) waiting to be serviced. This makes it very easy to starve
    the timers with long request queues, and so miss critical timestamps.
    
    The timer subsystem is just another input waiting to be serviced, so
    evaluate it on every loop like all the others, at the cost of calling
    GetTimeInMillis() slightly more frequently. (A more invasive and likely
    OS specific alternative would be to move the timer wheel to the local
    equivalent of timerfd, and treat it as an input fd to the event loop
    exactly equivalent to all the others, and so also serviced on every
    pass. The trade-off being that the kernel timer wheel is likely more
    efficiently integrated with epoll, but individual updates to each timer
    would then require syscalls.)
    
    Reviewed-by: Peter Harris <pharris@opentext.com>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

?
Comment 3 Thomas Lindroth 2018-07-29 19:15:27 UTC 
Looks like that patch went into xorg-server-1.20.0 and I'm still using 1.19.5. I tried to apply the patch over the 1.19.5 version (a bad idea perhaps?) and built xf86-video-intel at commit af36a4ab78cc0e2a85fa40d442bfb92df75dd217. That stutters like before.
Comment 4 Martin Peres 2019-11-27 13:49:48 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/issues/156.

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.