Bug 505485 - Various slowdowns on intel (glxgears, scrolling in firefox)
Various slowdowns on intel (glxgears, scrolling in firefox)
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
: Tracking, Triaged
Depends On: 504048 521080
Blocks: fedora-x-target
  Show dependency treegraph
Reported: 2009-06-12 00:40 EDT by Jason Merrill
Modified: 2016-05-12 09:06 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-05-12 09:06:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
dmesg output (52.67 KB, text/plain)
2009-11-08 17:53 EST, Jason Merrill
no flags Details
Xorg.0.log (47.99 KB, text/plain)
2009-11-08 17:53 EST, Jason Merrill
no flags Details

  None (edit)
Description Jason Merrill 2009-06-12 00:40:12 EDT
Description of problem:

glxgears is less than half as fast as it was under Fedora 8.
Scrolling in Firefox makes Xorg eat the CPU, which it didn't do in Fedora 8.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. glxgears
2. scroll up and down in a Firefox window
Actual results:

1. ~400 fps
2. scrolling lags behind input and uses 100% of the CPU Firefox is on.

Expected results:

1. ~900 fps as in Fedora 8.
2. No lag, moderate CPU consumption

Additional info:

00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)

This is a Thinkpad T61 6464Y1E.
Comment 1 Jason Merrill 2009-06-14 17:08:03 EDT
Booting with nomodeset (and therefore using EXA acceleration) increases glxgears fps to ~775.  Trying to use XAA acceleration makes the X server segfault.

The scrolling lag seems related to bug 504048, though in that case EXA is slower than UXA.
Comment 2 Kristian Høgsberg 2009-06-15 09:51:10 EDT
Are you using a xorg.conf file?  Can you try without it?  Is it the combination of glxgears and scrolling that's slow?  Does any real OpenGL application feel slower?  Do you have a 3D game you can use for benchmarking instead?
Comment 3 Jason Merrill 2009-06-15 10:37:21 EDT
I was using a trivial xorg.conf file to try and test XAA mode, but results are similar without it.

In Extreme Tuxracer running at at 1680x1050 I get about 16fps at the start of the course with UXA and about 20fps with EXA.  These are rough averages from watching the fps meter with the game paused; can you suggest a better game for benchmarking?

Also, under UXA I can't adjust the resolution in Extreme Tuxracer.  I changed it from the default of 800x600 to 1680x1050, the only other option, and now I can't change it to anything else.  Under EXA there are many resolution options.
Comment 4 Matěj Cepl 2009-06-15 11:18:54 EDT
(In reply to comment #2)
> Are you using a xorg.conf file?  Can you try without it?  Is it the combination
> of glxgears and scrolling that's slow?  Does any real OpenGL application feel
> slower?  Do you have a 3D game you can use for benchmarking instead?  

(hint: extremetuxracer is considered a cool OpenGL game)
Comment 5 Jason Merrill 2009-06-24 17:04:39 EDT
I noticed that http://qa-rockstar.livejournal.com/7869.html suggests the teapot benchmark from mesa-demos, so I tried it out with my F11 install and various LiveCDs:

F8: ~140 fps with help display on, ~160 with it off.

F9: ~55 fps with help on, ~82 with help off.  (Says "Failed to initialize TTM buffer manager" on start)

F10: ~102 fps with help on, ~126 with it off.  About 103/129 forcing XAA.

F11 EXA: About the same as F10.

F11 UXA: ~90 fps with help on, ~95 with it off.
Comment 7 Matěj Cepl 2009-11-05 13:31:27 EST
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command

yum upgrade --enablerepo='*-updates-testing'

Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD .

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
Comment 8 Jason Merrill 2009-11-08 01:32:07 EST
With the Fedora 12 beta (UXA) I see:

glxgears 625 fps
teapot 100fps w/ help, 106 w/o

Still quite a bit slower than F8.
Comment 9 Matěj Cepl 2009-11-08 05:08:08 EST
(In reply to comment #8)
> With the Fedora 12 beta (UXA) I see:
> glxgears 625 fps
> teapot 100fps w/ help, 106 w/o
> Still quite a bit slower than F8.  

Please attach your X server config file (/etc/X11/xorg.conf, if available), output of the dmesg command, and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below.

Thanks in advance.
Comment 10 Jason Merrill 2009-11-08 17:52:38 EST
It occurred to me that the F12 beta was a few weeks old now, so I went back and tried again with desktop-i386-20091107.20.iso, with better results:

glxgears 890 fps
teapot 107/117 fps
gtkperf 10s

teapot is still quite a bit slower than under F8, and gtkperf still takes about twice as long to run as with the vesa driver, but there is some improvement.
Comment 11 Jason Merrill 2009-11-08 17:53:23 EST
Created attachment 368094 [details]
dmesg output
Comment 12 Jason Merrill 2009-11-08 17:53:57 EST
Created attachment 368095 [details]
Comment 13 Zdenek Kabelac 2009-12-02 11:04:11 EST
Aren't you using on-demand CPU governor during your test ?
It could make some difference to use perfomance governor.
Comment 14 Adam Williamson 2010-02-10 16:02:19 EST
how'd it do in f12 final?

Fedora Bugzappers volunteer triage team
Comment 15 ra 2010-02-11 11:46:53 EST
on my x60s the performance on f12 (default config) is reasonable good (~380fps in glxgears) but not as good as it should be (~880fps)
Comment 16 Adam Williamson 2010-02-11 13:09:54 EST
glxgears is not a benchmark, please use a real game or gtkperf at least.

Fedora Bugzappers volunteer triage team
Comment 17 Zdenek Kabelac 2010-02-12 05:09:28 EST
I'd really like to know, why there is so so big problem with accepting the fact, that 'glxgears' shows low numbers because Intel driver performs in some areas slower then it used to be.

With XAA architecture many things in 2D graphics were actually a lot faster then they are now - just check various numbers with x11perf - even VESA driver is faster then Intel with many operation. Most probably there is set of operation where offloading them to GPU costs probably more, that processing them directly on CPU.

So 'glxgears' shows that processing single set of triangles is now slower than it used to be - simply because there is a lot of ping-pong between kernel KMS driver and user-space part of this Intel driver. 

Note: Now in fact Intel driver accelerate more operations in 3D (which is of course very good thing!)  thus in many games numbers are getting a lot better because of this (i.e. XAA had a lot of emulation code done by CPU).

IMHO there is no point to deny users that they are using wrong tools to measure numbers.  If I run busy loop counter - I'll measure core speed of my ALU in CPU, so why 'glxgears' isn't taken as a core measurement of the triangle processing speed - what is so broken with 'glxgears'?

Do we have any other officially accepted simple benchmark for simple 3D operations? (imho 3D game is way too complex and too many things influences overall FPS)

I think everyone sees the reality - while in fact many 3d games are now much better, overall 2D performance or very simple 3D apps is in fact slower.

And speaking of my numbers with 'glxgears' nowadays on my rawhide machine.

I'm getting over ~1000FPS  with T61 2.2GHz. It used to be over ~1200FPS in some very dark ages of history (like Fedora8). But overall it's now pretty good, as there were a long period of time (F10, F11) where it couldn't get faster than 700FPS.  So the current performance is quite good.
Comment 18 ra 2010-02-12 12:21:28 EST
imho there is no real need for benchmarking since the 3d performance is noticable _that_ much slower..

GtkPerf 0.40 - Starting testing: Fri Feb 12 18:15:24 2010

GtkEntry - time:  0.04
GtkComboBox - time:  1.60
GtkComboBoxEntry - time:  1.49
GtkSpinButton - time:  0.19
GtkProgressBar - time:  0.30
GtkToggleButton - time:  0.53
GtkCheckButton - time:  0.16
GtkRadioButton - time:  0.24
GtkTextView - Add text - time:  1.27
GtkTextView - Scroll - time:  0.04
GtkDrawingArea - Lines - time: 11.25
GtkDrawingArea - Circles - time: 12.69
GtkDrawingArea - Text - time:  6.56
GtkDrawingArea - Pixbufs - time:  1.27
Total time: 37.64

urbanterror is hardly playable..
Comment 19 Jason Merrill 2010-04-30 16:36:46 EDT
With desktop-x86_64-20100423.23 live image I get 100/115fps in teapot and about 12s total time from gtkperf; still very slow.
Comment 20 Adam Jackson 2012-02-09 15:15:47 EST
Are we happy with F16 (or F17)?  GM965 isn't the fastest chip in the world but it should be significantly better these days.
Comment 21 Jason Merrill 2012-05-15 11:29:40 EDT
With F16:

glxgears ~1014 fps
teapot ~50 fps

GtkEntry - time:  0.06
GtkComboBox - time:  1.14
GtkComboBoxEntry - time:  0.98
GtkSpinButton - time:  0.12
GtkProgressBar - time:  0.08
GtkToggleButton - time:  0.16
GtkCheckButton - time:  0.10
GtkRadioButton - time:  0.13
GtkTextView - Add text - time:  0.19
GtkTextView - Scroll - time:  0.21
GtkDrawingArea - Lines - time:  1.59
GtkDrawingArea - Circles - time:  0.91
GtkDrawingArea - Text - time:  0.90
GtkDrawingArea - Pixbufs - time:  0.21
Total time:  6.80

Scrolling in the browser has no lag and does not monopolize a CPU.

So, looks significantly better apart from curiously low FPS in teapot.  The scrolling problem that was my primary complaint before is definitely fixed.
Comment 22 Jason Merrill 2012-05-15 11:32:26 EDT
Oops, that testing was with an Arrandale laptop, not the GM965 I was using before.  Disregard those numbers, I'll test with the 965 soon.
Comment 23 Adam Jackson 2012-09-06 14:30:31 EDT
Had a chance to look at this yet?
Comment 24 Zdenek Kabelac 2012-09-07 02:51:15 EDT
Personally I'm more then satisfied with performance of SNA driver -  UXA is boringly slow - especially if Firefox has some more tabs opened.....

And just for inspiration of speed of SNA driver with GM965 

x11perf -aa10text:

24000000 reps @   0.0003 msec (3470000.0/sec): Char in 80-char aa line (Charter 10)

It used to be just 300000 with UXA....

Gears with performance governor (2.2GHz) are over 1300 FPS (with my debug kernel)
with on demand it drops to 1100FPS which is still pretty good.

I doubt UXA will reach this state since I've not seen any real development of UXA for a long time....
Comment 25 Zdenek Kabelac 2012-09-07 02:54:52 EDT
And here some gtkperf for my 2.2GHz T61:
(SNA driver)

gtkPerf 0.40 - Starting testing: Fri Sep  7 08:52:55 2012

GtkEntry - time:  0,03
GtkComboBox - time:  0,86
GtkComboBoxEntry - time:  0,67
GtkSpinButton - time:  0,15
GtkProgressBar - time:  0,11
GtkToggleButton - time:  0,13
GtkCheckButton - time:  0,09
GtkRadioButton - time:  0,13
GtkTextView - Add text - time:  0,19
GtkTextView - Scroll - time:  0,13
GtkDrawingArea - Lines - time:  1,05
GtkDrawingArea - Circles - time:  1,11
GtkDrawingArea - Text - time:  0,24
GtkDrawingArea - Pixbufs - time:  0,09
Total time:  4,98
Comment 26 Hans de Goede 2016-05-12 09:06:28 EDT
Last comment on this bug is from 2012, sna, with which everyone in this bug seems to be happy has been the default for quite a while now, closing.

Note You need to log in before you can comment on or make changes to this bug.