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.

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?

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.

(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)

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.

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.]

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.

(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.

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.

Created attachment 368094 [details]
dmesg output

Created attachment 368095 [details]
Xorg.0.log

Aren't you using on-demand CPU governor during your test ?
It could make some difference to use perfomance governor.

how'd it do in f12 final?



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

on my x60s the performance on f12 (default config) is reasonable good (~380fps in glxgears) but not as good as it should be (~880fps)

glxgears is not a benchmark, please use a real game or gtkperf at least.



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

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.

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..

With desktop-x86_64-20100423.23 live image I get 100/115fps in teapot and about 12s total time from gtkperf; still very slow.

Are we happy with F16 (or F17)?  GM965 isn't the fastest chip in the world but it should be significantly better these days.

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.

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.

Had a chance to look at this yet?

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....

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

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.