Entire screen jumps? Or does the update just stutter?

If the entire screen shifts/wobbles, then we have an output issue - which is not too surprising on Crestline. echo 7 > /sys/modules/drm/paramater/debug should produce some warnings in dmesg.

If just the updates stalls, we have a performance issue.

no, it's just the update that hangs for a short time (about 1/10 second?), just noticeable and annoying after some time...

echo 7 > /sys/modules/drm/paramater/debug tells me it can't find file/folder.
After that dmesg says that composite sync is not supported, but it has this error message on several places all over dmesg, and I forgot to check before I did the echo command...

I mistyped this morning, the correct path should have been:
/sys/module/drm/parameters/debug

Based on your observation though, I would say this was more of sw latency issue. I think latencytop might be the most interesting place to start, also iotop and possibly perf top. If you have transparent huge pages enabled, I'd disable them as well.

Eugeni, do you have any inspiration for ideas on how to detect random and transient slowdown?

o.k., I installed latencytop and iotop (didn't find perftop). What next? How do I disable transparent huge pages? I just learned that this would be a drawback for general performance, right?

I've seen a very similar problem which was actually caused by the disk activity (ext3 writebacks). Could you run 'vmstat 1' in a terminal, and verify if there are sudden increases in the 'bi' or 'bo' columns somewhere around the moment where the slowdown happens?

Other than this, it also looks very similar to the missing IRQ issue (except that I've never seen it on a non-Ivy bridge machine).

Could you also attach your dmesg please?

(In reply to comment #5)
> o.k., I installed latencytop and iotop (didn't find perftop).

perf top should be available in the linux-tools package. Though it is only going to be useful if the stalls correlate with a CPU spike, or if we hit an unusual i915_gem_request_wait_begin tracepoint.

> What next? How do
> I disable transparent huge pages? I just learned that this would be a drawback
> for general performance, right?

To disable thp, one needs to recompile the kernel without that feature. I mentioned them because of a bug were they conspired with compaction to aggravate io stalls - which is what my first guess as to the cause of your random stalls would be (the io stalls, though not necessarily due to thp).

O.k., real quick before I need to leave: I ran vmstat 1 and then started glxgears. The bigger jerks were accompanied by bo spikes (between 12-50). The jerks in vlc were not, though (although it always had bi values around 200, but no spikes). I'll also attach my dmesg.

Now that we have a vague idea that is related (at least in part) to io, can you also compare how SNA performs on your setup. Download xf86-video-intel.git and configure with --enable. Thanks.

*--enable-sna. D'oh.

O.k. Haven't done such a thing yet, used xorg-edgers repository so far. How do I use it? Should I install the git packages? I'm using (K)ubuntu 11.10.

Alongside ppa:xorg-edgers there is a ppa:intel-sna that replaces the standard ddx, with one compiled with ./configure --enable-sna.

Well, it doesn't find the intel-sna ppa. There is one called intel-gfx-testing/...
I have done compilation of packages in the past (the ./configure - make - make install stuff), so I might dare trying...

How did you get on tracking down an sna repo or compiling xf86-video-intel?

Whilst in the compiling frame of mind, can you build git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git and run trace-cmd record -e i915 during a period when it is stuttering and attach the trace.dat?

Well, there obviously has been a mutual waiting for input...
I found the intel-sna ppa and installed the xorg drivers from there, but the jerks remain so far. Vmstat gave similar outputs - jerks appear close to high bo/bi numbers.

I've never done that git thing before. How do I do it? Is there a place to get me started with it, like a how to?

On Ubuntu, compiling xf86-video-intel is something like
$ apt-get build-dep xserver-xorg-video-intel
$ git clone git://git.freedesktop.org/git/xorg/driver/xf86-video-intel
$ cd xf86-video-intel
$ ./autogen.sh --prefix=/usr --enable-sna
$ make && make install

But if you have intel-sna already, that is usually current (to within a day or so of xf86-video-intel.git) so just verify you are using SNA by grepping /var/log/Xorg.0.log for SNA.

What you can do next though is to start recording what is happening within the driver and see if we can spot any significant latencies. For this, trace-cmd is the ideal tool (git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git) and used like "trace-cmd record -e i915" produces a trace.dat file which will be large and hopefully interesting.

xorg.log says:

Information	[    49.937] (II) intel(0): SNA initialized with Broadwater backend

concerning trace-cmd: it's in the repos, so I installed it from there. How long should I let it run?

As short as possible around the jerk. :)

It's a needle-in-the-haystack problem. We need enough steady state behaviour (a fraction of a second) to know the background, and then hopefully identify a sequence associated with the issue.

O.k., it took a while (I have problems with rsi syndrom...). The file is about 4.3mb, you can find it here:
https://skydrive.live.com/redir.aspx?cid=f0e28a93bc8b35a1&resid=F0E28A93BC8B35A1!352&parid=F0E28A93BC8B35A1!165

Another interesting thing: when pressing ctrl-c, trace-cmd gave exited with this message:

CPU: 0
entries: 0
overrun: 0
commit overrun: 0

CPU: 1
entries: 0
overrun: 0
commit overrun: 0

but says, everything should be zero... Maybe another hint?

The trace.dat has the good stuff, no worries.

Ok, kwin is also rendering using GL. Out of curiosity what happens if you either disable desktop effects or use a non-compositing window manager?

even when running kwin with deskotp effects disabled, I still have those jerks. The only thing is, that it is much less prone to screen lockups... (which is another topic, I know... ;-)

Should I make a new trace.dat with desktop effects disabled?

(In reply to comment #22)
> Should I make a new trace.dat with desktop effects disabled?

Please do. Hopefully it will reduce the number of rendering processes to just X, making the trace easier to interpret.

I have replaced the trace.dat file at the above location with another one made from within icewm.

Maybe the same location, but it now has a new url. :)

Heres the link:
https://skydrive.live.com/redir.aspx?cid=f0e28a93bc8b35a1&resid=F0E28A93BC8B35A1!353&parid=F0E28A93BC8B35A1!165

At first glance, we're not blocking on the GPU so no obvious causes for driver related stutter. I might be able to discern some pattern to the frequency in which we submit commands to the driver and how long they take to complete (and so spot if there was any frame lag), but that's only going to be a missed vblank or so. More micro-stutter, the effect of fluctuating between 30Hz-60Hz update, and doesn't sound like the issue you are describing.

In this simplified icewm setup, I would run latencytop and see where it points the finger.

Well, there's an interesting thing now: when disabling desktop effects in kde, glxgears doesn't stutter any more. After reenabling, glxgears starts stuttering again. The same with vlc playing a dvd. So it looks more like a interference from kwin now. I don't know whether this is new, I think I tried disabling kwin effects before and it didn't work.

also framrate in glxgears drops to ~49fps when enabling kwin effects. After disabling, it syncs with the display, so is around 59fps.

Well we've quite possibly fixed one bottleneck in X, but still have issues with the complex interplay of renderering between X<->compositor(kwin). That kwin, due to mesa, regularly blocks the driver for 5-10ms, could be a source of small stutters (again amounting to missed vblanks).

Can you double check your observation about what combinations of software are required to cause the annoying stuttering?

(In reply to comment #29)
> also framrate in glxgears drops to ~49fps when enabling kwin effects. After
> disabling, it syncs with the display, so is around 59fps.

Right that's the effect of missing vblanks due to mesa blocking in the compositor. And a good concrete measure for us to investigate.

O.k., I checked with vlc, dragon and glxgear with kwin effects enabled/disabled. They all showed the same behaviour: stutters with kwin effects enabled and smooth displays with kwin effects disabled (well, there were a few tiny stutters at the beginning of playback, but that seems normal to me).

We've been discussing the possibility of reducing some lock contention within the kernel, and I think it might be of some relevance here. (Though I think we also suffer from vblank stalls). Can you try using a kernel built from http://cgit.freedesktop.org/~ickle/linux-2.6/log/?h=stutter

Can you give me a few pointers? I've setup a default install of KDE plasma desktop from Ubuntu on a 965gm and it seems reasonably smooth, glxgears hitting 60fps without much issue - until I move a window, and then it is unable to maintain 60fps. What else should I try to recreate your scenario?

I just upgraded to 12.04 64bit (complete wipe and fresh install, as I wanted to switch to 64bit). In general, the behaviour is still the same:

- glxgears with kde effects enabled is choppy, without it's smoother, but the frame rate is the same.

- In vlc video playback is smoother with kde effects disabled, although there are still stutters every second or so.

Should I enable xorg-edgers and intel-sna again for further testing? My machine is a dell latitude inspiron 1525. Could it be that it has a customized non-standard gm965?

(In reply to comment #35)
> Should I enable xorg-edgers and intel-sna again for further testing? 

Please do, though at the moment my hopes lie more towards the lockless-wait patches for the kernel.

> My machine
> is a dell latitude inspiron 1525. Could it be that it has a customized
> non-standard gm965?

No, it is probably just a combination of secondary effects, HDD latency with fairly slow memory. However, there is usually enough scope for the vendors to do something peculiar with strange register settings and evil system management mode/acpi!

Observing the lockless-wait patches, I can confirm that do help to reduce jitter. I don't see the same degree as you do, but wiggling glxgears under a compositor is much, much smoother now.

I'm convinced that the lockless-wait patches are the panacea here, and would love to get some feedback.

that would require to compile a custom kernel, right? I've never done such a thing before, where would I start? (Well, I did, but that was 1997 with Suse 5.2 and only with the standard sources from CD...).

Essentially ask google how to do that for your distro - all distros have pretty excellent howtos for kernel compilation. For beginners I suggest you build a native distro package (deb or rpm or whatever), that makes uninstalling much easier in case something goes wrong ;-)

I'd just like to mention that this exact bug has been irritating me for a really long time! I'm so happy I found this bug report.  

I'm running Gnome 3 and putting it into fallback mode (disabling compositing)
fixed this problem entirely.  

So, I'm kind of torn.  I like composited desktops and think it's the first time something "different" is being done in the desktop space.  However, a man needs his games. :D  

Is there any information I could provide or intel xorg.conf options I could try to fix this with compositing?

On a quick guess you want

commit 3236f57a0162391f84b93f39fc1882c49a8998c7
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Aug 24 09:35:09 2012 +0100

    drm/i915: Use a non-blocking wait for set-to-domain ioctl


which is included in the latest drm-intel-next kernel available at

http://cgit.freedesktop.org/~danvet/drm-intel

And a quick git for bug reporters howto to get you started:

http://blog.ffwll.ch/2012/05/git-for-bug-reporters.html

I believe as 3.7-rc1 with the aforementioned patches, we have reduced the contention within i915.ko to be point where the next major issue will lie elsewhere...