Description of problem: 3D performance is poor as long as the CPU is relatively idle. If at least one core is busy, 3D performance is great. Version-Release number of selected component (if applicable): kernel-2.6.33.2-43.fc13.x86_64 xorg-x11-drv-intel-2.10.0-4.fc13.x86_64 How reproducible: This is a little difficult to measure, since at present glxgears seems to generate quite a bit of CPU load itself (more than 60% in my case), so it may not be the best way to demonstrate the problem. It turns out this affects Fedora 12 with the same hardware and as glxgears there uses around 10%, its framerate numbers are much more illustrative of what I'm seeing. Perhaps Compiz is the simplest way to measure this, however the Compiz benchmark plugin will only show framerates up to approximately the monitor's vertical refresh rate. Steps to Reproduce with glxgears: 1. In Gnome, add the CPU Frequency Scaling Monitor to a panel and set the CPU to either the Performance setting or the maximum available clock speed. (This is for measurement consistency only.) 2. Run glxgears and watch the output. 3. Enter this in a terminal to create CPU load on one core: $ nice bash -c "while true; do true; done" 4. You can repeat step 3 for any remaining CPU cores. Steps to Reproduce with Compiz: 1. In Gnome, add the CPU Frequency Scaling Monitor to a panel and set the CPU to either the Performance setting or the maximum available clock speed. (This is for measurement consistency only.) 2. Enable the Compiz Benchmark plugin using CompizConfig and initiate the benchmark popup (default key binding is <Super>+<F12>). 3. Enter this in a terminal to create CPU load on one core: $ nice bash -c "while true; do true; done" Actual results: Framerates start very low until CPU is under load, then framerates climb to many times the original measurements. Expected results: Framerates should start relatively high when the system isn't busy. Additional info: Smolt profile: http://www.smolts.org/client/show/pub_f4f93912-ae8a-4775-a857-86312a387e84
A new version of the Intel driver, xorg-x11-drv-intel-2.11.0-1.fc13, has just been added: https://admin.fedoraproject.org/updates/xorg-x11-drv-intel-2.11.0-1.fc13 . Can you please test with this version and see if the bug is reproducible? If you have an installed Fedora 13, you can download and install the driver from the Koji link. If you are testing with live images, the nightly live images from 2010-04-17 (or possibly 2010-04-18) onwards should include this version: http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/ . This comment is being added to all open Fedora 13 intel bugs, please ignore if it does not make sense in the context of your bug.
Using xorg-x11-drv-intel-2.11.0-1.fc13, there seems to be some improvement in the base performance, but the phemonena is still clearly there. New wrinkles: glxgears now seems locked at the refresh rate of the monitor (60 or 74.69 FPS in my case) so it's not very useful as a benchmark. On the up side, its CPU usage is way down now. Compiz seems to start with a high framerate based on the Compiz benchmark plugin, but now the maximum reported framerate is 1/2 the monitor's refresh rate (30 or 37.3 FPS here), though the perceived framerate is often considerably higher. So now, with Compiz enabled the framerate starts at a fairly stable 36-38 FPS and lightweight effects like Scale (with three open windows) are far smoother than before, but more intensive effects like Expo (with curve and 2x2 virtual desktops) slows down considerably. Interestingly, simply moving the mouse around the screen gives the framerate a brief boost when the framerate is low. Making just one core busy still makes a huge difference. Idle framerate is a rock-solid 37.34 FPS with no fluctuation whatsoever. Scale is noticeably smoother and Expo is dramatically smooth. For both effects, the measured framerate barely flinches before returning to exactly 37.34 FPS. Here are the framerates reported by the Compiz benchmark plugin: Compiz effect Minimal load One busy core (of two) Idle 36-38 FPS 37.34 FPS Scale (3 windows) 25-26 FPS 37.34 FPS Expo (with curve) 9-10 FPS 37.34 FPS
I'm experiencing very poor 3D performance with Intel GM45 integrated graphics on my lenovo T500. $ glxgears 299 frames in 5.0 seconds = 59.626 FPS 299 frames in 5.0 seconds = 59.797 FPS 299 frames in 5.0 seconds = 59.795 FPS In F12 this is running 500+ FPS Version-Release number of selected component (if applicable): kernel-2.6.33.3-73.fc13.x86_64 xorg-x11-drv-intel-2.11.0-2.fc13.x86_64
*** Bug 587369 has been marked as a duplicate of this bug. ***
Adjusting title as it doesn't really correspond with current situation. The performance is very poor IMO regardless what the cpu usage is.
Created attachment 410189 [details] Xorg log
Created attachment 410190 [details] /var/log/messages
IMO this will affect a lot of users thus should have higher priority
Should the new behaviour (i.e. framerate being clamped to monitor refresh rate) be a new bug rather than hijacking this one?
Miroslav, could you try reproducing my original bug? I'm not convinced that the clamped framerate is really an issue here. Realistically, a monitor can't display rendered frames any faster than the monitor's refresh rate, so the fact that glxgears showed such high frame rates seems more like an academic benchmark rather than a measurement of what you see on the screen. Enter this on a terminal and see if you see an improvement in the smoothness of 3D rendering while it's running, regardless of the actual reported framerate: nice bash -c "while true; do true; done"
Ira, I tried it and the 3D preformance seem fine to me when cpu is under load also (of course the frame rate is clamped as you reported in comment #2). I changed back the title of the bug and will reopen my "dupe" for tracking the clamped framerate issue. When testing I got a screen freeze (without hard lockup) once, but I couldn't reproduce it anymore after (it happened with running glxgears and rotating the desktop cube). Looks like I'm expericing the behaviour described here: http://lists.freedesktop.org/archives/intel-gfx/2010-April/006652.html
(In reply to comment #10) > Miroslav, could you try reproducing my original bug? Can I ask you to install mesa-demos package and try to measure performance with something else than glxgears (e.g., teapot)? See http://qa-rockstar.livejournal.com/7869.html for more about problems with glxgears. Thank you
I'm seeing exactly the same behaviour from teapot: - Running only teapot, I get 32-36 fps and the animation is very unsteady. - If I make one of my two cores busy, teapot shows 57-59 fps with my monitor set to 60 Hz refresh rate and 71-73 fps at 75 Hz refresh rate with only occasional glitches in the animation. - If I make both cores busy, teapot shows 59-61 fps at 60 Hz and 74-75 fps at 75 Hz with no visible flaws in the animation smoothness at all. Refresh rate No load One core load Two core load 60 Hz 32-36 fps 57-59 fps 59-61 fps 75 Hz 35-39 fps 71-73 fps 74-76 fps I'm still seeing the frame rate significantly improve when the CPU is busy and as well as that the frame rate appears to scale with the refresh rate of my monitor. Stab in the dark: Does this sound like something to do with interrupts?
I think the OP of this forum thread: http://forums.fedoraforum.org/showthread.php?t=244492 has the same issue. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
For me, updating to latest intel driver, xserver and mesa will solve this problem.
Can you be more specific: 1. What is your video chipset 2. What drivers version solved your issue. Thanks.
Intel GMA 4500MHD Before, the performace is very low. But upgrading to this xorg-x11-drv-intel-2.11.0-4.fc13.x86_64 kernel-2.6.33.3-85.fc13.x86_64 mesa 7.8.1-6.fc13.x86_64 The performance issues has been solved.
My i915GM on i686 works the same way with kernel-2.6.33.3-85 and xorg-x11-drv-intel-2.11.0-4. Those updates for my did make any changes. My bug: https://bugzilla.redhat.com/show_bug.cgi?id=589420.
Sorry, I meant: "Those updates for my video card did NOT make any changes."
I'm still seeing this problem in F13 and in up-to-date F14 Alpha. lspci shows my graphics as "Intel Corporation 82Q33 Express Integrated Graphics Controller". My F14 currently has these packages: kernel-2.6.35.4-28.fc14.x86_64 xorg-x11-drv-intel-2.12.0-6.fc14.x86_64 mesa-*-7.9-0.6.fc14.x86_64
I just booted another PC with the same hard drive with F14 on it, but this desktop has integrated ATI graphics ("ATI Technologies Inc RS482 [Radeon Xpress 200]"). It's showing exactly the same symptoms with 3D accelleration. I'm not sure where this bug belongs now. My previous tests with F13 on this same ATI-based hardware didn't show the performance improvements when putting the CPU under load, so I'm not sure what's going on here. I'll have to retest with up-to-date F13. In the meantime, does anyone have a suggestion about where this bug belongs?
Well, I can confirm that this phenomena exists ... when I run (with xorg-x11-server-Xorg-1.9.0-9.fc14.x86_64 and xorg-x11-drv-intel-2.12.0-6.fc14.x86_64) stress --cpu 1 (that's from package stress, very useful tool) then framerate in teapot SLIGHTLY increases. But really, just slightly, like from 38 to 42 or in this range. What's your hardware? CPU? memory? What's the output of the command glxinfo |grep render Thank you
Here is my smolt profile for F14 on the Intel hardware: http://www.smolts.org/client/show/?uuid=pub_ec55aaca-dd7a-40d0-9414-ecf2fac1897d The short version: Intel 6.0 GHz Core 2 Duo, 2 GB RAM [thub@localhost ~]$ glxinfo | grep render direct rendering: Yes OpenGL renderer string: Mesa DRI Intel(R) Q33 GEM 20100330 DEVELOPMENT
*Ahem* That should be "Intel 3.0 GHz Core 2 Duo"
After some more thorough teapot tests in F14, I've got the following results which are somewhat different than what I'm seeing in F13. Metacity: WM/Desktop Idle "stress --cpu 1" Metacity 55-60 fps[1] 55-60 fps gnome-shell 6-9 fps[2] 55-60 fps Compiz 40-46 fps 55-60 fps 1: While teapot is running, moving windows around, particularly causing Metacity to repaint previously hidden windows or partially covering the teapot window, makes the screen update slowly and the window doesn't drag smoothly. 2: While teapot is running, the screen updates too slowly to keep up with typing in the terminal. The rest of the time, typing on the keyboard seems to be the only thing other than CPU load that speeds up the screen updates under gnome-shell.
As long as I also have sent here my experience, I would like to say, that with: OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Intel(R) 915GM GEM 20100330 DEVELOPMENT OpenGL version string: 1.4 Mesa 7.9-devel xorg-x11-server 1.9.0-9.fc14 kernel 2.6.35.4-28.fc14.i686.PAE Glxgears: 196 frames in 5.0 seconds = 39.111 FPS - mouse is still 196 frames in 5.0 seconds = 39.150 FPS - mouse is still 277 frames in 5.0 seconds = 55.270 FPS - mouse is moving around 296 frames in 5.0 seconds = 59.108 FPS - mouse is moving around Hope it helps. Thanks
(In reply to comment #26) > Glxgears: See the link in comment 12 for glxgears.
I'm not a fedora user, but i've the same issues (and package version) as sd.domrep. As we all understand that glxgears is not a benchmark, it's a bit strange that just moving the mouse around or pressing and releasing any key causes it to boosts its performance. Also, i noticed the same issue with compiz benchmark, it jumps from 40 to 60fps as soon as i keep my finger on the touchpad (still or moving makes no difference). And its not all about benchmark anyway, the expo plugin (compiz) is very choppy (around 20fps), but as soon as i... you know, it jumps to 30. Of course you will not notice it if you are playing a game, but still is annoying. For the record, reverting to kernel 2.6.33 fixes this issue. Out of curiosity, i'm going to try mesa demos.
Teapot demo from mesa exhibits the exact same behaviour as glxgears. just launching it under linux-2.6.33 gives stable 30fps (my refresh rate halved,60/2,vsync issue, but it's ok). launching it under linux-2.6.35 gives 14~15fps (60/4), and guess what... just touching the touchpad makes the magic: 30fps.
I just wanted to ping this bug since it's the Intel Graphics Test Day for F14 and I'm still getting the same behaviour with the Test Day LiveCD. Interestingly though, while teapot still has this problem, now glxgears (the prescribed testing tool for the Test Day) is now behaving just fine and adhering to the refresh rate -- unless there's some compiz stuff going on at the same time.
I filed a bug to upstream, probably related: https://bugs.freedesktop.org/show_bug.cgi?id=30364
*** Bug 639062 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > Description of problem: > 3D performance is poor as long as the CPU is relatively idle. If at least one > core is busy, 3D performance is great. This bug isn't exclusive to redhat/fedora nor is it cpu load exclusive (even tho it is indirectly affected by it). when a opengl & intel & vsync driver application is taxed it will seem smooth since it isn't in real danger of matching (exceeding?) the refresh rate. Un-taxing the application (with opengl,intel,vsync) will take a normal greater than or around 59 fps (with sync) all the way down to < 15 . moving the app about the screen, sending the app signals to process speeds up the framrate (assumed that your app will not try to ride to sync rate when doing so) .The folks at redhat should be able to track down the sync limit code and check? , I am sure that this is what is afflicting opengl apps with stutter and in return yielding low fps. bug verified/observed with. kernel 2.6.35-24 intel driver 915gm
*** Bug 697195 has been marked as a duplicate of this bug. ***
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping