Bug 65115 - [sna ivb] rendering is getting painfully slow sometimes
Summary: [sna ivb] rendering is getting painfully slow sometimes
Status: RESOLVED NOTOURBUG
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-29 08:16 UTC by Jiri Slaby
Modified: 2013-07-19 06:41 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
xorg.log (69.84 KB, text/plain)
2013-05-29 08:16 UTC, Jiri Slaby
no flags Details
i915_gem_objects snapshots (24.25 KB, text/plain)
2013-05-29 10:57 UTC, Jiri Slaby
no flags Details
perf report of Xorg (2.06 MB, text/plain)
2013-07-01 11:21 UTC, Jiri Slaby
no flags Details

Description Jiri Slaby 2013-05-29 08:16:30 UTC
Created attachment 79937 [details]
xorg.log

I use opengl+KDE4 and when some effects are performed, it stutters a bit. So I enabled FPS "effect" and it shows 60 FPS and a dropdown to 20 or less when I move windows, move with sliders in windows, minimize etc. There are red or even black peaks in the FPS effect.

This happens after some uptime I believe. If I run a new X while the stuttering is still running (by creating a new session), the new one works fine (60 FPS, no peaks). Is there any way to find out what is going on?
Comment 1 Daniel Vetter 2013-05-29 08:33:55 UTC
Please retest with 2.21.8 which fixes a leak which is known to cause such stuff ...
Comment 2 Jiri Slaby 2013-05-29 08:35:55 UTC
(In reply to comment #1)
> Please retest with 2.21.8 which fixes a leak which is known to cause such
> stuff ...

You mean bug 64978? I have the fix already (as I hit that):
$ git log --color 51103d8..2.21.8
commit 7e7d0ad15bafc4624f8c2ccf73c08ead5cc6fd6a
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon May 27 13:41:13 2013 +0100

    2.21.8 release
Comment 3 Chris Wilson 2013-05-29 09:12:15 UTC
Tricky. It sounds like GPU latency with vsync enabled. A couple of things to watch would be perf top and intel_gpu_top, comparing and contrasting the stutters. Keeping an eye on /sys/kernel/debug/dri/0/i915_gem_objects for another leak would be very useful as well. There is a bug whereby creating and destroying DRI2 drawables will leak XIDs leading to slowdown over time - that will show up as an increase in time spent in X walking linear lists.
Comment 4 Jiri Slaby 2013-05-29 10:54:20 UTC
(In reply to comment #3)
> Tricky. It sounds like GPU latency with vsync enabled. A couple of things to
> watch would be perf top and intel_gpu_top, comparing and contrasting the
> stutters. Keeping an eye on /sys/kernel/debug/dri/0/i915_gem_objects for
> another leak would be very useful as well. There is a bug whereby creating
> and destroying DRI2 drawables will leak XIDs leading to slowdown over time -
> that will show up as an increase in time spent in X walking linear lists.

Ok, I had to reboot. I will try perf and intel gpu top when it happens again. In the meantime I ran
  # while :; do
    cat /sys/kernel/debug/dri/0/i915_gem_objects > i915_gem_objects-`date +%s`
    sleep 60
  done

after reboot and see this:
# head -1 -q *
958 objects, 254709760 bytes
999 objects, 256397312 bytes
985 objects, 256159744 bytes
1065 objects, 275365888 bytes
1176 objects, 313335808 bytes
1126 objects, 323555328 bytes
1200 objects, 328904704 bytes
1137 objects, 320385024 bytes
1135 objects, 321847296 bytes
1137 objects, 320401408 bytes
1316 objects, 379543552 bytes
1190 objects, 333225984 bytes
1244 objects, 340979712 bytes
1143 objects, 318935040 bytes
1155 objects, 328417280 bytes
1199 objects, 335335424 bytes
1282 objects, 331145216 bytes
1166 objects, 314241024 bytes
1175 objects, 333467648 bytes
1224 objects, 328019968 bytes
1196 objects, 318615552 bytes
1186 objects, 318578688 bytes
1181 objects, 318525440 bytes
1180 objects, 318492672 bytes
1158 objects, 318345216 bytes
1166 objects, 318435328 bytes
1166 objects, 318435328 bytes
1167 objects, 318468096 bytes
1170 objects, 318451712 bytes
1166 objects, 318435328 bytes
1169 objects, 318476288 bytes
1224 objects, 334139392 bytes
1368 objects, 355901440 bytes
1390 objects, 370708480 bytes
1370 objects, 338788352 bytes
1368 objects, 338780160 bytes
1256 objects, 329981952 bytes
1258 objects, 329990144 bytes
1269 objects, 330035200 bytes
1314 objects, 332021760 bytes
1278 objects, 331870208 bytes
1354 objects, 364048384 bytes
1331 objects, 355749888 bytes
1597 objects, 383066112 bytes
1478 objects, 345219072 bytes
1474 objects, 345186304 bytes
1400 objects, 344682496 bytes
1434 objects, 344592384 bytes
1413 objects, 344477696 bytes
1403 objects, 344436736 bytes
1408 objects, 341217280 bytes
1418 objects, 341258240 bytes
1418 objects, 341258240 bytes
1418 objects, 341258240 bytes
1418 objects, 341258240 bytes
1447 objects, 342118400 bytes
1435 objects, 341430272 bytes
1501 objects, 357027840 bytes
1495 objects, 352120832 bytes
1431 objects, 364711936 bytes
1443 objects, 349376512 bytes
1486 objects, 358604800 bytes
1385 objects, 331812864 bytes
1423 objects, 340115456 bytes
1458 objects, 347058176 bytes

Does it show something to you? I can tar it all and attach if you are interested.
Comment 5 Jiri Slaby 2013-05-29 10:57:15 UTC
Created attachment 79950 [details]
i915_gem_objects snapshots

(In reply to comment #4)
> I can tar it all and attach if you are interested.

It's not that much, attaching in plain.
Comment 6 Chris Wilson 2013-05-29 11:13:01 UTC
The number of objects looks fairly benign at the moment; nothing to suggest more than normal system activity.
Comment 7 Chris Wilson 2013-05-30 12:38:24 UTC
Hmm, how about plain old top? I think I've seen something scary, I hope I am hallucinating...
Comment 8 Jiri Slaby 2013-05-31 06:53:32 UTC
(In reply to comment #7)
> Hmm, how about plain old top? I think I've seen something scary, I hope I am
> hallucinating...

I don't see it yet again, after 2d uptime. I think I need to do something to trigger it. That "something" is unknown to me yet :/...
Comment 9 Jiri Slaby 2013-05-31 07:09:39 UTC
(In reply to comment #3)
> watch would be perf top and intel_gpu_top

FWIW when I run intel_gpu_top, my machine freezes hard after a while. (This was the reason for "I had to reboot" above btw.)
Comment 10 Chris Wilson 2013-06-12 12:35:08 UTC
I'll give this some time to see if it reappears and subjects itself to scrutiny.
Comment 11 Chris Wilson 2013-06-30 08:41:23 UTC
Any news? Let me know if you find anything I can help with.
Comment 12 Jiri Slaby 2013-07-01 11:18:52 UTC
It needed you to close that to see it again. So now it stutters with 2.21.10-51-g48b5ac1. i915_gem_objects looks sane I think:
1999 objects, 354684928 bytes
1488 [513] objects, 272773120 [65654784] bytes in gtt
  2 [1] active objects, 1323008 [4096] bytes
  1486 [512] inactive objects, 271450112 [65650688] bytes
77 unbound objects, 13459456 bytes
189 purgeable objects, 18591744 bytes
29 pinned mappable objects, 9093120 bytes
1 fault mappable objects, 57344 bytes
2145386496 [268435456] gtt total

'perf top' shows Xorg at ~40% with GetXIDRange.

intel_gpu_top freezes my machine hard, so I won't try it.

(Still haven't rebooted nor I plan to do so in the near future.)
Comment 13 Jiri Slaby 2013-07-01 11:21:37 UTC
Created attachment 81795 [details]
perf report of Xorg
Comment 14 Chris Wilson 2013-07-01 11:32:35 UTC
Ah, GetXIDRange(). Yes, I've heard of that one before; iirc it is a KDE client (plasma-desktop) leaking resources and so consuming large number of XIDs. GetXIDRange() is not the most efficient of beasts.

Last couple of threads:

http://lists.x.org/archives/xorg-devel/2012-November/034555.html
http://lists.x.org/archives/xorg-devel/2013-May/036311.html
Comment 15 Jiri Slaby 2013-07-01 11:41:52 UTC
(In reply to comment #14)
> http://lists.x.org/archives/xorg-devel/2012-November/034555.html

citing:
> which I tracked to an application (psi)
> continuously pushing pixmaps to plasma-desktop to achieve a pulsating
> icon in the system tray.

That's definitely it. Killing and restarting plasma-desktop frees the misc resources from xrestop and the system is responsive as usual again ;).
Comment 16 Jiri Slaby 2013-07-19 06:41:33 UTC
This is now fixed:
https://bugs.kde.org/show_bug.cgi?id=314919


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.