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)
Created attachment 28829 [details] Xorg.0.log
Performance regression also affects GM45
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.
How about if you disable SwapbuffersWait (in xorg.conf, under intel Device section)?
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)
Created attachment 28998 [details] This is the Xorg log from when I changed the SwapbuffersWait option Added xorg log
Created attachment 28999 [details] xorg.conf - SwapbuffersWait - disabled
You are using the same version of etracer between the two, right?
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.
Eric says this is caused by DRI2, unblocking Q3 release.
Ivan, along with the same etracer, are you using the same compositing setup between the two systems?
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.
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.
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.
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.
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.