Bug 38735 - [945GM SNA] extremely slow gtk
Summary: [945GM SNA] extremely slow gtk
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Daniel Vetter
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-28 01:01 UTC by Paul Neumann
Modified: 2017-07-24 23:04 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Gtkperf results from the 2 versions (1.11 KB, text/plain)
2011-06-28 01:01 UTC, Paul Neumann
no flags Details
Xorg log from 2.15 with Uxa (24.11 KB, text/plain)
2011-06-28 01:02 UTC, Paul Neumann
no flags Details
Xorg log from git version with SNA (24.50 KB, text/plain)
2011-06-28 01:03 UTC, Paul Neumann
no flags Details
Separate fence pin counting from normal GTT counting (10.62 KB, patch)
2011-06-28 01:18 UTC, Chris Wilson
no flags Details | Splinter Review
Results from running perf (13.46 KB, application/octet-stream)
2011-06-28 13:05 UTC, Paul Neumann
no flags Details

Description Paul Neumann 2011-06-28 01:01:50 UTC
Created attachment 48505 [details]
Gtkperf results from the 2 versions

Hi

When I am using xf86-video-intel from git with --enable-sna, Gtk rendering is extremely slow. Gtkperf takes about multiple times as long and the whole UI is sluggish. However, when I use version 2.15, everything is smooth.

The kernel version is 3.0-rc5

My card is:

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
Comment 1 Paul Neumann 2011-06-28 01:02:32 UTC
Created attachment 48506 [details]
Xorg log from 2.15 with Uxa
Comment 2 Paul Neumann 2011-06-28 01:03:03 UTC
Created attachment 48507 [details]
Xorg log from git version with SNA
Comment 3 Chris Wilson 2011-06-28 01:18:41 UTC
Created attachment 48508 [details] [review]
Separate fence pin counting from normal GTT counting

This bug is the cause of quite a severe regression on gen3.
Comment 4 Chris Wilson 2011-06-28 01:42:12 UTC
Just to compare my system:

uxa:

GtkEntry - time:  0.00
GtkComboBox - time:  0.40
GtkComboBoxEntry - time:  0.26
GtkSpinButton - time:  0.04
GtkProgressBar - time:  0.02
GtkToggleButton - time:  0.04
GtkCheckButton - time:  0.04
GtkRadioButton - time:  0.08
GtkTextView - Add text - time:  0.55
GtkTextView - Scroll - time:  0.09
GtkDrawingArea - Lines - time:  0.55
GtkDrawingArea - Circles - time:  1.66
GtkDrawingArea - Text - time:  0.26
GtkDrawingArea - Pixbufs - time:  0.08
 --- 
Total time:  4.06

sna:

GtkEntry - time:  0.00
GtkComboBox - time:  0.38
GtkComboBoxEntry - time:  0.22
GtkSpinButton - time:  0.04
GtkProgressBar - time:  0.02
GtkToggleButton - time:  0.04
GtkCheckButton - time:  0.04
GtkRadioButton - time:  0.08
GtkTextView - Add text - time:  0.55
GtkTextView - Scroll - time:  0.09
GtkDrawingArea - Lines - time:  0.39
GtkDrawingArea - Circles - time:  0.67
GtkDrawingArea - Text - time:  0.26
GtkDrawingArea - Pixbufs - time:  0.05
 --- 
Total time:  2.83
Comment 5 Chris Wilson 2011-06-28 01:44:10 UTC
Also note that we have complicating factors such as WM and theme to consider.
Comment 6 Chris Wilson 2011-06-28 01:53:25 UTC
And for strict comparison, 2.15.0:

GtkEntry - time:  0.00
GtkComboBox - time:  0.39
GtkComboBoxEntry - time:  0.26
GtkSpinButton - time:  0.04
GtkProgressBar - time:  0.02
GtkToggleButton - time:  0.04
GtkCheckButton - time:  0.04
GtkRadioButton - time:  0.08
GtkTextView - Add text - time:  0.55
GtkTextView - Scroll - time:  0.09
GtkDrawingArea - Lines - time:  0.54
GtkDrawingArea - Circles - time:  0.63
GtkDrawingArea - Text - time:  0.26
GtkDrawingArea - Pixbufs - time:  0.07
 --- 
Total time:  3.01

Which has the Lines/Circles acceleration that was latter disabled in UXA due to its inherent bugs.
Comment 7 Chris Wilson 2011-06-28 05:31:05 UTC
Hmm, I reverted that patch on my test machine and saw no change. Obviously that's not the explanation...
Comment 8 Chris Wilson 2011-06-28 06:04:15 UTC
Ok, I'm seemingly haven't found the key to reproducing this. Can you please report how much the CPU is busy and attach some perf profiles?
Comment 9 Paul Neumann 2011-06-28 09:33:19 UTC
When using SNA, the X process takes 100% CPU time for the duration of the benchmark.
I would provide the perf profiles if you could tell me how to so or point me to where I find an introduction.

Thanks
Comment 10 Chris Wilson 2011-06-28 10:03:04 UTC
Under Ubuntu, perf is packaged as linux-tools. Once installed use:

$ sudo perf record -f -g -a
# time passes
ctrl-C
$ sudo perf report | head -500

Now if that just shows a load of addresses, then you will need to install all the dbg packages for your system. Of particular importance are the kernel and xserver dbg.deb

Then once we have symbol resolution, attach the output of perf report. Thanks.
Comment 11 Paul Neumann 2011-06-28 13:05:00 UTC
Created attachment 48529 [details]
Results from running perf

I ran `perf record ...` during the Gtkperf run. There are so many symbols missing but I hope this is not bad as there is this 60% chunk (I'm on Arch and have to recompile the packages for debugging info, which is no problem itself, just time consuming).

If I have to get more symbols in there, just let me know.

Thanks for your help.
Comment 12 Chris Wilson 2011-06-28 13:16:55 UTC
Ok, with so much clflush its likely to be the fence pin-counting bug mentioned above. More depth in the symbol resolution would help...
Comment 13 Paul Neumann 2011-06-29 07:50:08 UTC
I did some more testing concerning themes and window managers. It seems that the window manager makes no difference but the theme does. If I choose a theme based on the Murrine Gtk engine, everything is slow. However, when I choose any other Gtk theme, it is just fine. The window manager makes no difference in performance as xfwm4 is just as fast as twm.

I will continue to recompile the libraries to get a better perf result.
Comment 14 Chris Wilson 2011-06-29 08:20:19 UTC
Can you please try the kernel patch?
Comment 15 Paul Neumann 2011-06-29 08:36:59 UTC
Well, this patch does fix my problem.

Thanks for your help
Comment 16 Eugeni Dodonov 2011-08-30 15:53:33 UTC
@Chris - did the patch got into the upstream kernel? Or it is still pending?
Comment 17 Chris Wilson 2011-08-31 01:29:32 UTC
The patch is still waiting to be blessed.
Comment 18 Chris Wilson 2012-01-26 12:18:14 UTC
Daniel, I believe you have the fence pin counting fix queued already?
Comment 19 Daniel Vetter 2012-01-26 12:23:35 UTC
It's not yet queued into offical d-i-n, but I plan to pick up the fixes and error_state improvements over the next few days.
Comment 20 Daniel Vetter 2012-02-08 02:20:42 UTC
Patch merged to drm-intel-next, on track to be merged into 3.4.
Comment 21 Florian Mickler 2012-04-05 06:51:30 UTC
A patch referencing this bug report has been merged in Linux v3.4-rc1:

commit 1690e1eb7a9021826853e181baa48dd77090da28
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Dec 14 13:57:08 2011 +0100

    drm/i915: Separate fence pin counting from normal bind pin counting


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.