Red Hat Bugzilla – Bug 855560
F18 Live Alpha : nVidia GeForce 8600M GT, graphic driver (nouveau): very poor performance (vesa is fluid)
Last modified: 2014-09-13 14:57:47 EDT
Created attachment 611097 [details]
TC6 var-log folder, dmesg, free, ps aux and xsession-errors
Description of problem:
As soon as F18 Live KDE session as loaded, CPU is very highly used, while just moving or refreshing any window (90%). At idle it goes down. This makes the whole experience awful.
Version-Release number of selected component (if applicable):
F18 Live KDE alpha TC5 and TC6
Steps to Reproduce:
1. Boot until KDE Session is launched
2. Open any window, eg. Dolphin
Just moving the window around, using the mouse :
- with desktop effects : X 50% + kwin 40%
- without desktop effects : X 50% + kwin 5%
Anything reasonable :)
Asus V1S laptop with nVidia GeForce 8600M GT (hence nouveau)
F16 and F17 Live KDE, do not bring this issue
Until Beta, we use a debug kernel, which performs much more poorly than a release kernel. Try with a non-debug kernel to see if that helps, if you can. Unless you try that, it's hard to know whether there's any other performance issue. The other thing to check would be that nouveau is actually loaded and acceleration is working (Xorg.0.log).
Discussed at 2012-09-10 QA meeting, acting as a blocker review meeting. For now this is rejected on the grounds that poor performance is expected with Alpha due to the debug kernel. If there appears to be a significant problem over and above the influence of the debug kernel, please re-propose.
More precisely : using *nouveau*, performance is so bad that performance can be felt even just moving the cursor around (redering makes some micro-pauses) or writing a text file in Kwrite (some of the keystrokes are getting "lost", 10% maybe).
Yesterday I tested both Gnome & KDE Live alpha RC2 isos : default boot gives the same results for both.
Then I also tried *vesa*, which I had not tried so far :
- under KDE, all is great during the whole session, perfectly fluid ! Even with Desktop Effects enabled, and despite high CPU usages even higher than I reported previously. X alone takes almost 100% while moving a Dolphin window around the 1024x768 screen, but there is no drastic experience penalty, it remains fluid. So, KDE over vesa just performs, at least, as well as anyone would expect on such hardware (T7500, 4GB RAM, 2007 GPU with 512 dedicated VRAM).
- under Gnome, vesa is as fluid as with KDE, but only at the very start of Gnome session. Then it gets slower and slower as the session lasts, up to the point the experience is comparable to that of nouveau described previously :s Since this is gradual, and while KDE behaves well, I assume that's a distinct issue.
Also, while booting vesa (please see bug 855557), animation loads in text mode/lowres (which is expected, this time ^^), but it *does* scales properly to full screen display, until GDM/KDM is launched (versus screen being drawn within the top left quarter of the LDC panel, and some [OK] messages appearing "at the last text line of the top right quarter").
Should I close bug 855557 as duplicate, and re-propose this one as a blocker ?
Created attachment 612125 [details]
alpha RC2/KDE/nouveau var-log, tmp, free, ps aux, lsmod, dmesg, xsession-errors
Created attachment 612126 [details]
alpha RC2/KDE/vesa var-log, tmp, free, ps aux, lsmod, dmesg, xsession-errors
Created attachment 612127 [details]
alpha RC2/Gnome/vesa var-log, tmp, free, ps aux, lsmod, dmesg
Applies to Alpha (RC3). See also bug 857300.
Does the fix for 857300 improve this behaviour at all?
Seeing the same issue on Thinkpad W520 - GF108 [Quadro 1000M) (rev a1)
Very poor performance - even mouse slow to move and/or jerky.
I'm running the kernel referenced in bug 857300 - 3.6.0-0.rc6.git0.2
(In reply to comment #9)
> Seeing the same issue on Thinkpad W520 - GF108 [Quadro 1000M) (rev a1)
> Very poor performance - even mouse slow to move and/or jerky.
> I'm running the kernel referenced in bug 857300 - 3.6.0-0.rc6.git0.2
I think llvmpipe is used as OpenGL rendered on your machine. Check glxinfo and try to boot this machine with "nouveau.noaccel=0".
oh, for anyone who comes across this bug, if you started X with 'startx', you are almost certainly seeing https://bugzilla.redhat.com/show_bug.cgi?id=806491 . boot runlevel 5, or use 'startx -- vt01'.
Discussed at 2012-10-04 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-04/f18-beta-blocker-review-2.1.2012-10-04-16.00.log.txt . We agreed we need more information on what's going on before we can evaluate this. Can you please test it with Beta TC1 or TC2 when available ( http://dl.fedoraproject.org/pub/alt/stage/ ), and advise exactly what kernel you're using for each test? Can you please provide the output of glxinfo as well so we can check whether nouveau or llvmpipe is being used? Thanks.
Discussed at 2012-10-10 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-10/f18beta-blocker-review-3.2012-10-10-16.05.log.txt . As we haven't received a reply to the above question, and we haven't seen more people reporting this issue either here or on the list or in the forums, we're considering this to be an issue with fairly narrow impact and rejecting as a blocker for now. If more information comes to light it can be re-proposed.
This appears to be fixed, tested Fedora-18-Beta-TC6-x86_64-Live-KDE.iso