Bug 505485

Summary: Various slowdowns on intel (glxgears, scrolling in firefox)
Product: [Fedora] Fedora Reporter: Jason Merrill <jason>
Component: xorg-x11-drv-intelAssignee: Adam Jackson <ajax>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: ajax, awilliam, ceski, hdegoede, mcepl, tim.faber, xgl-maint, zkabelac
Target Milestone: ---Keywords: Tracking, Triaged
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-05-12 13:06:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 504048, 521080    
Bug Blocks: 432388    
Attachments:
Description Flags
dmesg output
none
Xorg.0.log none

Description Jason Merrill 2009-06-12 04:40:12 UTC
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):

xorg-x11-drv-intel-2.7.0-7.fc11.i586

How reproducible:

Always

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 21:08:03 UTC
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 13:51:10 UTC
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 14:37:21 UTC
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 15:18:54 UTC
(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 21:04:39 UTC
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 18:31:27 UTC
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 06:32:07 UTC
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 10:08:08 UTC
(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 22:52:38 UTC
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 22:53:23 UTC
Created attachment 368094 [details]
dmesg output

Comment 12 Jason Merrill 2009-11-08 22:53:57 UTC
Created attachment 368095 [details]
Xorg.0.log

Comment 13 Zdenek Kabelac 2009-12-02 16:04:11 UTC
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 21:02:19 UTC
how'd it do in f12 final?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 15 ra 2010-02-11 16:46:53 UTC
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 18:09:54 UTC
glxgears is not a benchmark, please use a real game or gtkperf at least.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 17 Zdenek Kabelac 2010-02-12 10:09:28 UTC
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 17:21:28 UTC
imho there is no real need for benchmarking since the 3d performance is noticable _that_ much slower..

anyway:
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 20:36:46 UTC
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 20:15:47 UTC
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 15:29:40 UTC
With F16:

glxgears ~1014 fps
teapot ~50 fps

gtkperf:
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 15:32:26 UTC
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 18:30:31 UTC
Had a chance to look at this yet?

Comment 24 Zdenek Kabelac 2012-09-07 06:51:15 UTC
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 06:54:52 UTC
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 13:06:28 UTC
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.