Bug 23433

Summary: [GM965] Extreme Tux Racer shows 66% performance regression compared with Hardy
Product: xorg Reporter: Bryce Harrington <bryce>
Component: Driver/intelAssignee: Eric Anholt <eric>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: a, brian, jerrylamos, sarelgrin, stetzen
Version: 7.4 (2008.09)Keywords: NEEDINFO, regression
Hardware: All   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg.0.log
none
This is the Xorg log from when I changed the SwapbuffersWait option
none
xorg.conf - SwapbuffersWait - disabled none

Description Bryce Harrington 2009-08-20 20:16:39 UTC
Forwarding this bug from Ubuntu reporter Ivan Stetsenko:
http://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/416073

[Problem]
Extreme Tux Racer shows a significant 66% performance regression compared with Hardy.

[Original Description]
I've been experiencing it since clean install of alpha2, but now I've booted from Hardy LiveDVD and done some benchmarking.

Extreme Tux Racer IS a benchmark, isn't it?

Game settings: all graphics extras are disable, except from FPS; 800x600 resolution.

Hardy: ~60 FPS
Karmik: ~20 FPS

3 times drop!

glxgears (definitely not a benchmark, but...)

Hardy: 4200 frames in 5 secs
Karmik: 1400 frames in 5 secs

3 times drop again. And compiz feels slower as well.

Lenovo R61i with X3100

libgl1-mesa-dri                      7.5-1ubuntu1
xserver-xorg-video-intel             2:2.8.0-0ubuntu2
libdrm-intel1                        2.4.12-1ubuntu1
xserver-xorg                         1:7.4+3ubuntu5
linux-image-2.6.31-5-generic         2.6.31-5.24

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 0c)
Comment 1 Bryce Harrington 2009-08-20 20:17:06 UTC
Created attachment 28829 [details]
Xorg.0.log
Comment 2 Sarel Grinberg 2009-08-24 07:50:07 UTC
Performance regression also affects GM45
Comment 3 Ivan Stetsenko 2009-08-26 12:37:23 UTC
After an update to mesa 7.6.0~git20090817.7c422387-0ubuntu2 things became better. I've noticed a 75% performance increase, but 35 fps are still much lower than 60 fps with 7.0.3~rc2-1ubuntu3.
Comment 4 Gordon Jin 2009-08-27 22:30:50 UTC
How about if you disable SwapbuffersWait (in xorg.conf, under intel Device section)? 
Comment 5 Sarel Grinberg 2009-08-29 00:26:09 UTC
Well, I changed the SwapbuffersWait setting to false (I also had to write a xorg.conf file since ubuntu 9.10 comes without it). 

Performance didn't show any change, however something is changed because the tearing is back now. Tried to re-enable the SwapbuffersWait but no change. The tearing continues unless I delete the new xorg.conf (which is extremely minimal and ordinary)

Anyways the SwapbuffersWait doesn't matter to the performance. windows still don't move very smoothly, tux racer gives the same framerate (it's even slightly better with the original configuration, 35fps-SwapbuffersWait off, 38fps-original)

compiz and kwin performance is still bad. (and with tearing)
Comment 6 Sarel Grinberg 2009-08-29 00:46:36 UTC
Created attachment 28998 [details]
This is the Xorg log from when I changed the SwapbuffersWait option

Added xorg log
Comment 7 Sarel Grinberg 2009-08-29 00:48:22 UTC
Created attachment 28999 [details]
xorg.conf - SwapbuffersWait - disabled
Comment 8 Eric Anholt 2009-08-31 19:15:36 UTC
You are using the same version of etracer between the two, right?
Comment 9 anli 2009-09-14 03:52:48 UTC
I can confirm with KDE effects being turned on I have etracer's fps ~2x slower rather at case when effects are turned off (or, instead of KDE, just using, say, fluxbox). Up to date Kubuntu Karmic (testing) is in use. My card is Intel X3000.
Comment 10 Gordon Jin 2009-09-15 00:18:17 UTC
Eric says this is caused by DRI2, unblocking Q3 release.
Comment 11 Eric Anholt 2009-09-24 18:47:20 UTC
Ivan, along with the same etracer, are you using the same compositing setup between the two systems?
Comment 12 anli 2009-09-24 18:57:42 UTC
In KDE it is sufficient to press Alt-Shift-F12 to "toggle" performance almost 2 times *on-the-fly* - i.e. with the same instance of currently running etracer.
Comment 13 Ivan Stetsenko 2009-09-25 08:24:34 UTC
Sorry for the delay with providing info...

extremetuxracer 0.4-2ubuntu1, which is a default version from karmik repo.

I'm using default KDE compositing, kde-window-manager 4:4.3.1-0ubuntu8, again default karmik version

Secondly (it looks like I've forgot to mention it in the original report), the regression I'm talking about can be observed in the fullscreen mode; if the application is fullscreen, the performance does not depend from compositing. I mean, Hardy's 60 FPS and Karmik's 30 fps are both fullscreen.

If I'm running etracer in windowed mode, it shows the same lower performance (30 fps) if compositing is enabled and even lower performance (15-20 fps) with compositing. So there are two separate bugs here, I think.
Comment 14 Eric Anholt 2009-12-08 21:17:00 UTC
Looking at the profile of etracer on my GM45, there's not much we can do with this app --there may be a few percent to shave off total, but for the most part the cpu's being wasted on fixed function OpenGL handling.  framerate with default config is reported between 30 and 60 fps (sadly, there doesn't appear to be a demo mode that would make etracer a reliable benchmark application) regardless of whether I run xcompmgr -a or not.

To track down a regression, we're going to need to bring up the two systems side by side with sysprof and top.  Sadly, we won't be able to compare perf output between the two, which is the other key to performance debugging.
Comment 15 Eric Anholt 2010-12-28 16:20:16 UTC
Ivan, can you please retest without KDE compositing enabled to compare the performance between the two?  I'd like to get this closed out, but I can't see anything for us to do for this application under gnome.
Comment 16 Jeremy Huddleston Sequoia 2011-10-11 11:31:37 UTC
No response in 2 years.  Assuming fixed.  Please reopen if you can provide the 
information requested.

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.