Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 609790 - Slow graphics performance in new nouveau version
Slow graphics performance in new nouveau version
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau (Show other bugs)
14
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Ben Skeggs
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-01 02:30 EDT by Stefan Ring
Modified: 2012-08-16 18:30 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-16 18:30:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stefan Ring 2010-07-01 02:30:30 EDT
Description of problem:
Updated package makes my system noticeably slower

Version-Release number of selected component (if applicable):
0.0.16-7.20100423git13c1043.fc13

How reproducible:
Install this specific version of xorg-x11-drv-nouveau

Actual results:
Much slower graphics output than before, especially in xterm (using the "fixed" font). E.g., when I press Ctrl-R in bash, I can actually watch the area where the (reverse-i-search) prompt will go being cleared before the prompt appears.

Expected results:
Same performance as before


Additional info:
I just rebuilt the previous version (0.0.16-6.20100423git13c1043.fc13) and downgraded, and everything is back to normal. So I will stick with this version, for the time being.

Hardware: http://www.smolts.org/client/show/pub_dbe294f3-62e0-40f9-b141-547eeb979466
Quadro NVS 290
Comment 1 Petr Pisar 2010-07-01 03:29:18 EDT
The same problem with

01:00.0 VGA compatible controller [0300]: nVidia Corporation G96 [Quadro FX 380] [10de:0658] (rev a1) (prog-if 00 [VGA controller])
        Subsystem: nVidia Corporation Device [10de:063b]

Xorg.log diff:

--- Xorg.0.log.old      2010-07-01 08:46:53.177729301 +0200
+++ Xorg.0.log  2010-07-01 08:46:53.171729359 +0200
@@ -13,7 +13,7 @@
  Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
- (==) Log file: "/var/log/Xorg.0.log", Time: Wed Jun 30 08:16:27 2010
+ (==) Log file: "/var/log/Xorg.0.log", Time: Thu Jul  1 08:42:32 2010
  (==) Using config file: "/etc/X11/xorg.conf"
  (==) Using system config directory "/usr/share/X11/xorg.conf.d"
  (==) ServerLayout "Layout0"
@@ -338,12 +338,6 @@
  (II) NOUVEAU(0): Modeline "720x400"x70.1   28.32  720 738 846 900  400 412 414 449 -hsync +vsync (31.5 kHz)
  (**) NOUVEAU(0): Display dimensions: (470, 300) mm
  (**) NOUVEAU(0): DPI set to (90, 88)
- (II) Loading sub module "wfb"
- (II) LoadModule: "wfb"
- (II) Loading /usr/lib64/xorg/modules/libwfb.so
- (II) Module wfb: vendor="X.Org Foundation"
-       compiled for 1.8.0, module version = 1.0.0
-       ABI class: X.Org ANSI C Emulation, version 0.4
  (II) Loading sub module "fb"
  (II) LoadModule: "fb"
  (II) Loading /usr/lib64/xorg/modules/libfb.so
@@ -379,7 +373,6 @@
  (==) NOUVEAU(0): Silken mouse enabled
  (II) NOUVEAU(0): [XvMC] Associated with Nouveau GeForce 8/9 Textured Video.
  (II) NOUVEAU(0): [XvMC] Extension initialized.
- (II) NOUVEAU(0): NVEnterVT is called.
  (==) NOUVEAU(0): DPMS enabled
  (II) NOUVEAU(0): RandR 1.2 enabled, ignore the following RandR disabled message.
  (--) RandR disabled
@@ -404,6 +397,7 @@
  (II) AIGLX: Screen 0 is not DRI capable
  (II) AIGLX: Loaded and initialized /usr/lib64/dri/swrast_dri.so
  (II) GLX: Initialized DRISWRAST GL provider for screen 0
+ (II) NOUVEAU(0): NVEnterVT is called.
  (II) NOUVEAU(0): Setting screen physical size to 444 x 277
  resize called 1680 1050
  (**) Option "Protocol" "auto"
Comment 2 Ben Skeggs 2010-07-01 03:43:02 EDT
Also just with xterm?  This commit was expected to make some applications slower, but it fixes far far worse performance regressions (as in, completely unusable) in more modern apps.
Comment 3 Stefan Ring 2010-07-01 03:53:37 EDT
I also noticed it with Emacs, which uses the same font: "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-*-*"

If its expected to make things slower, then this is too slow. I guess VESA would be faster...
Comment 4 Stefan Ring 2010-07-01 04:01:05 EDT
Unfortunately, you mistyped the reference to the other bug its supposed to fix. It seems to be bug #596353. I've had glitches for ages, but only in the far right pixel columns (8 pixels or so), have not tried if they actually disappeared with -7.
Comment 5 Petr Pisar 2010-07-01 04:07:21 EDT
Xterm with with bitmap fonts is affected. Xterm with freetype font looks good. However painful is root-tail application that draws through gtk1 (bitmap fonts) system log on root window. Redrawing root-tail content under closed window is really slow.

First I though that randr acceleration has broken, but other GTK2 applications are fine. This seems like a problem with some legacy drawable caching mechanism.
Comment 6 Stanislav Ochotnicky 2010-07-28 07:46:24 EDT
One more app that is affected by this: rxvt-unicode is re-drawing terribly slow
Comment 7 Stefan Ring 2010-09-16 11:11:03 EDT
I just installed Fedora 14 Alpha in order to evaluate whether I should switch to it, but unfortunately, this problem persists even after after "yum update kernel* xorg*" and is enough of an annoyance to me to keep me from upgrading for some time.
Comment 8 Ben Skeggs 2010-10-10 21:02:52 EDT
I've pushed a version of xorg-x11-drv-nouveau that has an option to allow the old behaviour to be restored for users that want it.  This will not be done by default, as non-legacy rendering is negatively effected by this alternate rendering method.

http://koji.fedoraproject.org/koji/buildinfo?buildID=199899

With that installed, append 'Option "WrappedFB" "on"' to your device section of xorg.conf.
Comment 9 Adam Williamson 2010-10-11 12:31:53 EDT

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 10 Stefan Ring 2010-10-25 08:09:05 EDT
I verified that the WrappedFB option restores sane xterm performance. I'm wondering what the downside is, though.
Comment 11 Adam Williamson 2010-11-01 20:50:51 EDT

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 12 Ben Skeggs 2010-11-01 22:44:06 EDT
The downside is that in a number of other use cases, with more modern apps, WrappedFB causes severe performance regressions.
Comment 13 Henrique Martins 2010-11-03 16:30:31 EDT
And what are those more modern apps, so one can decide which way to go?
Comment 14 Ben Skeggs 2010-11-03 18:07:20 EDT
Firefox on certain pages, and OpenOffice Impress with certain slides.  For the latter, I had a slide as a test case that took about 30 seconds per frame to render.
Comment 15 Rui Matos 2011-05-22 11:56:16 EDT
(In reply to comment #8)
> With that installed, append 'Option "WrappedFB" "on"' to your device section of
> xorg.conf.

Without this option, Emacs is unusable under gnome-shell in a standard F15 install. Is there really nothing that can be done about this?
Comment 16 Rui Matos 2011-05-22 22:02:52 EDT
(In reply to comment #15)
> (In reply to comment #8)
> > With that installed, append 'Option "WrappedFB" "on"' to your device section of
> > xorg.conf.
> 
> Without this option, Emacs is unusable under gnome-shell in a standard F15
> install. Is there really nothing that can be done about this?

I just found out that disabling the scroll bars in Emacs works around this problem.
Comment 17 Stefan Ring 2011-07-07 11:53:13 EDT
Strangely enough, the system as a whole feels a lot less snappy without nouveau.noaccel=1 (that is, with acceleration enabled) than with it, which I've been running for over a year now (without acceleration).
Comment 18 Fedora End Of Life 2012-08-16 18:30:33 EDT
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

Note You need to log in before you can comment on or make changes to this bug.