GF8200 / Poor 2D performance / ETA of fix?

[zim2dive]

Originally Posted by Windseeker

Hmmm... I don't own a GF8 card, but out of the logic:
At the login screen you don't set any values with nvidia-settings, too. I bet your nvidia-settings is executed _after_ login from KDE/Gnome Autostart. So the problem could only be in some xorg.conf parameters or really a horrible bug in the driver or a broken card.

And before somebody is shouting "nonsense!": Yes, broken card could match the report as well, because the newer driver could perhaps trigger the fault whilst the older drivers didn't. I can't tell how likely this might be, but it is possible, too.

why is everyone so intent on finding some explanation (holding nvidia blameless) other than the most obvious (Occam's razor). No 8200 owners are reporting that they can play hulu HD in full screen with 177/180, but once we all switch back to 173 we can. How much more obvious do you want it to be?

Same piece of hardware works well with 173 and badly with 177/180 under linux.. but works flawlessly under Windows (will have to check the driver version).

Unless you own an 8200 and can share your perfectly working setup with those of us who do not, really you have nothing to contribute to this thread other than info which is no more applicable than a report about results using an ATI or Intel GPU. There are plenty of reports of folks with other nvidia GPUs, both above than the 8200 AND below the 8200 (in rated performance).. they are not having the issue.. the 8200 is.. what works for them has no relevance for us, even tho it would be nice if it did. I've tried the new 180 drivers, I've tried all the performance settings for the 177 drivers (which are on by default with 180).. none of them come close to the simple thing of rolling back to 173. It is a night and day difference. So they broke and/or removed something that was in 173 with regard to the 8200.

[apaige]

zim2dive: the only particularity in my config is Composite disabled, and the PixmapCache parameter for nvidia-settings. FYI, I don't run a login manager, and I put the nvidia-settings command in my ~/.xinitrc, so that it runs *immediately* after Xorg starts.

Beyond that, again, you're only talking about Flash, not 2D performance in general. It's a very specific problem. And the reason I'm not upset about it, is that flash performance under linux has always sucked. Hell, Adobe even made us wait for over two years before they released a 64-bit plugin.

NVIDIA isn't blameless, but you guys are really exagerating. Like I said, overall 2D performance is good on my setup. There's already a thread about flash performance, be specific and don't call it ALL crap when that's simply not true.

[Windseeker]

Originally Posted by zim2dive

why is everyone so intent on finding some explanation (holding nvidia blameless) other than the most obvious (Occam's razor).

So you think I hold Nvidia blameless if I assume the driver could have a horrible bug or the card is broken? Seems you should read my post before replying.

Originally Posted by zim2dive

Unless you own an 8200 and can share your perfectly working setup with those of us who do not, really you have nothing to contribute to this thread other than info which is no more applicable than a report about results using an ATI or Intel GPU.

I posted that the problem logically cannot rely on nvidia-settings options. This would point to a driver bug, no config problem. Logic doesn't need reproduction on my side. Seems you should read my post before replying.

Zim, you just want people to join you ranting, you don't want people to analyze the problem, think about the cause, guess what could help. Interestingly, you are so blind from anger, you even don't recognize that my assumtions even point in the same directions as yours do. This blindness will never help the reporter in first place.
Additionally, the first poster has even the login page rendering extremely slow, so your flash issues are not relevant here.
Perhaps after the reporter has stable 2D performance he might want to join your flash rants in your thread. Until that, your flash issues are off-topic here.

[zim2dive]

Originally Posted by apaige

Beyond that, again, you're only talking about Flash, not 2D performance in general. It's a very specific problem. And the reason I'm not upset about it, is that flash performance under linux has always sucked. Hell, Adobe even made us wait for over two years before they released a 64-bit plugin.

NVIDIA isn't blameless, but you guys are really exagerating.

No we're not there is a massive difference in performance from 173 to 177 .. going from full (or close) FPS on full screen flash, to a crippled 1-2 fps that eventually locks up and dies.

The (fatal) flaw in the logic here an so many other places is people keep saying 'flash has always sucked' therefore we never expect better.. AND yet with 173 Flash has very good performance with the 8200. Therefore we know there is something that can be massively improved within the nvidia driver, to get us back to 173 levels of performance. This provides a very specific test case for the devs to focus on.. and that is exactly the way you help debug, find a single, simple, repeatable test case.

[zim2dive]

Originally Posted by Windseeker

Zim, you just want people to join you ranting, you don't want people to analyze the problem, think about the cause, guess what could help.

Quite the opposite, I want folks to stop blaming everything except nvidia (ie Flash)

Additionally, the first poster has even the login page rendering extremely slow, so your flash issues are not relevant here.

Thread title is 2D.. is Flash not 2D?

Perhaps after the reporter has stable 2D performance he might want to join your flash rants in your thread. Until that, your flash issues are off-topic here.

The OP only posted

and when the system booted up I was really shocked. I never thought that 2D could be *that* *slow*.

I'm not trying to criticize the OP, but that's not an obvious test case for the devs to debug.. I'm simply trying to provide a very specific/repeatable test with a massive difference in performance from the works to not-works case... in case you've never done firmware debug, that is exactly what a dev needs.

Given the similarity in the cure (massive performance difference btw 173 and 177) these are very likely the same/related issue.

You plainly state you don't own an 8200... its not personal, but so far I've run into nothing but well-intentioned folks who own non-8200 GPUs posting fixes that simply aren't applicable. Given the localized nature of this bug, I don't think anyone without an 8200 (or that is not an nvidia dev) can contribute much... the tricks/hacks/gizmos that make the other cards work simply can't overcome whatever got broken in the jump from 173 to 177 (and beyond)

[X-Dimension]

Originally Posted by apaige

Yes I see all those threads, but they must be doing something different from me, because I have a 8300 and my desktop performance is not horrible slow (sic) at all. Windows get drawn instantly. Then again, the nvidia-settings command I run plays a big role in 2D performance.

Please tell us a little bit more about your system!
-> What linux distribution did you use
-> 32 or 64Bit
-> KDE or Gnome

I'm an IT specialist and most of the 35+ computers in our office are based on an Nvidia Geforce motherboard. Some are using the GF7050, some are using the GF8200. At home i have two Geforce 8300 based boards. (Asus M3N78 PRO and M3N78-EM)
I have done intensive tests in the last month since the 177.xx drivers comes out and it was the same on all boards:

-> Geforce 7050 based boards are working perfect with every driver here on Mandriva 2009 x86_64 & Gnome!
-> Geforce 8200 and 8300 boards are working also fine with 173.xx but they don't with 177.xx and 180.xx here.

Again i don't talk about flash performance because i personally don't use flash based websites very often.
What i talk about is pure 2D performance! When moving windows or open programs you can see how your screen is drawed line by line.

I will test the posted settings and will give you a feedback if it fixes my problem.

[X-Dimension]

Ok, i've tested the nvidia-settings -a InitialPixmapPlacement=1 command but it doesn't change anything here with 177.82.
I can also confirm now, that fullscreen flash works well with 173.14.12 driver here on my GF8300 based M3N78-EM, but the 177.82 driver gives only 1-2 frames per second.

[hitthenorth]

Wasn't sure as to which of the many threads with similar issues to post to, but just to add I seem to be experiencing the same issue with an integrated GF8300 on an ASUS M3N78-EM motherboard. The rest of the hardware is an AMD 4850e dual core processor, and 2GB of RAM,

I'm running Ubuntu 8.10 and the recommended 177.x driver and have mythtv installed on top of it.

Despite following all the recommended performance configuration - e.g. PixmapCacheSize etc, I see high CPU usage from xorg.

It is most noticeable when trying to use the mythtv Program Guide. Regardless of the shading option chosen, trying to scroll around the guide is incredibly painful due to the sluggishness. During this xorg's cpu usage goes shooting up from an already high value to using around 100% of one core. Trying to do the same in Live TV with the preview is near impossible.

Had thought about upgrading to a newer driver, but having read some comments on here and elsewhere decided to downgrade to the other intstalled driver - 173.x. Whilst still not exactly using low CPU, the difference is incredible. I can zip around the program guide.

Unfortunately this isn't a solution though as I lose my audio over HDMI to the television which was one of the main reasons for choosing this motherboard.

I hope this is going to be resolved quickly because everybody had recommended nvidia as the way to go for Linux.

[apaige]

Originally Posted by X-Dimension

Please tell us a little bit more about your system!

• Asus M3N78-EM motherboard (GeForce 8300 IGP), GeForce 8600GT discrete PCIe card (512MiB of on-board RAM)
• AMD Phenom 9600 quad-core CPU (2.3GHz) with TLB BIOS workaround *disabled* (I never run into the bug, so why suffer the performance penalty), virtualization disabled (I don't need it), Cool N' Quiet enabled (idles at 1.2GHz)
• 8GiB of DDR2-800 RAM (512MiB for the IGP, 5GiB ramdisk, which leaves 2.5GiB usable by the OS), dual channel, unganged mode
• Arch Linux x86_64, running a self-compiled linux kernel (vanilla 2.6.27.10, CONFIG_X86_PAT disabled, not sure if that makes a difference)
• xorg-server 1.5.3, NVIDIA driver 180.22, Openbox window manager version 3.4.7.2 (I don't run any desktop environment), GTK2 version 2.14.6
• /etc/X11/xorg.conf: Composite extension disabled, xtrap and record modules disabled (I don't need them), TripleBuffer on, TwinView off (I use two LCD panels, one of which connected to the 8300, the other one to the discrete 8600GT along with my TV via S-Video, each with their own X.org screen)
• ~/.xinitrc: nvidia-settings --config="$HOME/.nvidia-settings-rc" -l and nvidia-settings -a PixmapCacheRoundSizeKB=65536. I don't use a login manager.

Test cases that have been problematic with past NVIDIA driver releases:

• Firefox 3 with this page loaded (it has a fixed background): scrolling on that page used to be excruciatingly slow; it's smooth as silk with my current setup.
• Firefox 3 with the x86_64 Flash plugin version 10.0 d21: non-fullscreen animations and videos are smooth, but use a lot of CPU (and multiple cores, I might add). I don't even dare trying fullscreen video, for fear of crashing Firefox or locking up X.org: the x86_64 flash plugin is beta software, and I've had unpleasant experiences in the past.
• Firefox 3 with a large image loaded in it: switching to another workspace, then going back to Firefox's workspace within 15 seconds, is fast (the entire screen draws instantly); when waiting over 15 seconds, the display shortly freezes until it's done drawing (about a second).
• rxvt-unicode terminal, version 9.06: maximized window with no decorations, fake-translucent background (transparent, tintColor and shading properties enabled): it draws pretty slowly when Xft support is compiled in, but fast when Xft is disabled, which I don't mind because I like terminals to use a console font with no anti-aliasing.
• gtkperf -c1000: executes in about 75 seconds, with the scrolling test taking only 2.3 seconds. It used to be much slower than that (much more than 100 seconds, can't remember exactly). I'm using the "Mist" GTK2 theme, with gtk-xft-antialias=1, gtk-xft-hinting=1, gtk-xft-hintstyle=hintfull, gtk-xft-rgba=none, "DejaVu Sans 8" as default font.

I can't think of anything else right now.

[X-Dimension]

I see some differences between your setup and mine.

1. You are using a Phenom, but the people who talk about the problem here seems to have all an Athlon X2.
2. We are all using one of the major distros (Suse, Ubuntu, Debian, Fedora/Redhat, Mandriva) but you are using Arch with self compiled Kernel.
3. You don't use a Desktop Environment like KDE or Gnome but a small and fast window manager.
4. You have an add in graphics card but we are only have the IGP

If you have the time you could install Mandriva or Ubuntu with Gnome, remove your add in graphics card and test if you had the same performance like with your arch setup. If it works also fine for you than i think its a problem with Nvidia Geforce 8200/8300 based boards and AMD Athlon X2 CPUs only.

BTW: I've installed the 180.22 driver now, and it don't fix the problem here on my HTPC.
I will switch back again to 173.xx.

[apaige]

1. Shouldn't make a difference. All the problems we're talking about have little to do with how powerful the CPU is.
2. That's possibly a relevant parameter.
3. I'm not sure that makes a big difference, since Gnome also uses GTK2; the biggest difference is sub-pixel hinting, which I have disabled (gtk-xft-rgba=none), but can also be disabled in a DE. What may or may not be relevant is Metacity (Gnome's WM), which supports compositing (Openbox doesn't).
4. Changes nothing, since I have a separate X.org screen (as in, :0.0, :0.1, :0.2) and each device is independent; performance is different on the 8300 and on the 8600, in both 2D and 3D (the discrete 8600GT with its own on-board memory, higher frequency and simply higher feature set, is faster). In my previous post, I only talked about performance on the 8300.

As for taking the time to install a distribution that I loathe, that's not my role. I'm not the one with performance issues.

[Space]

Regarding point 2.:

I am running Gentoo (therefore everything+kernel compiled myself) and it's still very bad performance. I disabled composite extension and still have bad performance.

So from my point of view this is clearly an Nvidia issue:

- if I replace the 180.22 driver with the 173.14.15 one I have no problem
- if I do it vice versa I have a problem

No other change on the system. I moved from NVidia 7050 chipset (no problem) to 8200 chipset (problem) without any changes in software.

My understanding of Kepner-Tregoe just tells me two things: it depends on the 8200 chipset and every driver >173.14.15 has performance problems on this chipset. And that's not just 10% slower. It's more like 10 times slower. But that's nothing new to anyone except Nvidia. As soon as AMD releases something similar to VDPAU this board is to sell.

Bye,

Space