Can you please attach your Xorg.0.log and dmesg after a resume?

Created attachment 88544 [details]
Xorg.0.log after 3 suspends

I didn't notice this until now, but it seems it takes two or three suspends before the stuttering actually becomes noticeable.
Also ignore all the errors about wacom, that's an issue with one of the files in xorg.conf.d that I forgot to fix prior to posting this.

Created attachment 88545 [details]
dmesg after 3 suspends

So it appears this bug might not just be limited to suspend mode. I noticed recently I can reproduce it by locking and unlocking the screen in gnome a few times. So it may not be an issue with xf86-video-intel, but that's for you to decide I guess. Ether way I would really appreciate it if you knew what I could to to remedy this issue.

Chandler,

In the latest git versions of the driver I've been experiencing some stuttering myself, but I almost never suspend my laptop.  The easiest way to replicate the behavior I've been seeing has been to simply load up a large webpage in Chromium and start scrolling through it, up and down.  Within a few seconds, the chromium window will freeze only to unfreeze and "catch up" in a second or two.

The behavior is quite annoying but I haven't filed a bug report yet because I don't have any kind of log output that seems to correlate with the behavior.  Could you load up a large webpage and Chromium and see if you can replicate this behavior?  And if so, could you confirm whether or not it resembles the stuttering that you are complaining about here?

Jay

Note: This behavior is seen with both SNA and Tearfree enabled (haven't tried disabling Tearfree though I'm positive that turning off SNA and turning on UXA will resolve the issue, but that's not a road I'm willing to go down.  Also my laptop contains an Intel HD 4600.

If I turn off Tearfree, my issue seems to go away.  I wonder if what I'm seeing isn't actually more similar to this:

https://bugs.freedesktop.org/show_bug.cgi?id=70764

In any event, I'm not getting the kernel log entry, but perhaps I need to enable some more detailed drm logging.

(In reply to comment #5)
> Chandler,
> 
> In the latest git versions of the driver I've been experiencing some
> stuttering myself, but I almost never suspend my laptop.  The easiest way to
> replicate the behavior I've been seeing has been to simply load up a large
> webpage in Chromium and start scrolling through it, up and down.  Within a
> few seconds, the chromium window will freeze only to unfreeze and "catch up"
> in a second or two.
> 
> The behavior is quite annoying but I haven't filed a bug report yet because
> I don't have any kind of log output that seems to correlate with the
> behavior.  Could you load up a large webpage and Chromium and see if you can
> replicate this behavior?  And if so, could you confirm whether or not it
> resembles the stuttering that you are complaining about here?
> 
> Jay
> 
> Note: This behavior is seen with both SNA and Tearfree enabled (haven't
> tried disabling Tearfree though I'm positive that turning off SNA and
> turning on UXA will resolve the issue, but that's not a road I'm willing to
> go down.  Also my laptop contains an Intel HD 4600.

I've tried disabling tearfree. The behavior has changed, however it's not completely gone. Instead of multiple quick distinct stutters it's now a very consistent single stutter every few seconds that lasts longer.
I think this does have to do with the gnome-shell though, because restarting the shell makes everything go back to normal.

What does free report during the stuttering period? Perhaps top or sudo perf top. And similarly "cat /sys/kernel/debug/dri/0/i915_gem_objects"?

(In reply to comment #8)
> What does free report during the stuttering period? Perhaps top or sudo perf
> top. And similarly "cat /sys/kernel/debug/dri/0/i915_gem_objects"?

Okay, hopefully I did this in an acceptable manner.
I tried watching the output of watch -n .1 cat /sys/kernel/debug/dri/0/i915_gem_objects to see if there was any unusual changes during the stuttering period, but there didn't appear to be any. When doing the same with with free -m however, I think I might have seen one extra megabyte allocated every time the screen updated after the stuttering that seemed to be freed the next time watch updated it's output. If you want me to give a try checking the output via ssh as opposed to using the same machine let me know.

That's a fairly good indicator that we are not allocating new objects at least - but doesn't really help explain the stutters. Another issue might be RPS, in which case 3.13 should be more interesting.

Hi, I just noticed this got marked as "NEEDINFO", what kind of information do you need me to provide?

I want you to test the 3.13 kernel to see if this is an RPS effect. Though now I wonder if the BIOS is completely upsetting the RPS/rc6 code... Let's start with 3.13 any how.

The other thing to test would be whether the effect shows up in micro-benchmarks such as x11perf (-shmput500, -copywinwin500, -compwinwin500, -aa10text, would be reasonable choices to stress memory-bound performance).

(In reply to comment #12)
> I want you to test the 3.13 kernel to see if this is an RPS effect. Though
> now I wonder if the BIOS is completely upsetting the RPS/rc6 code... Let's
> start with 3.13 any how.

What do you mean by RPS?

RPS = render power states (otherwise known as GPU turbo). Basically the GPU goes to sleep when idle and tries to run at the lowest power settings (frequency i.e. speed) when busy.

I've been busy recently with other stuff so I just got the chance to put up an update on this. As it turns out it was an issue with GNOME and not with the video drivers. After updating from 3.8 to 3.10 the issue went away completely.