M3N78-VM onboard geforce 8200 and APG

[Icarus]

This threw me over the weekend. I got a new ASUS M3N78-VM motherboard and once I got all the drive ordering and networking figured out I felt it was time to play some Savage2 :D

I previously was using a Geforce 6800 x8 AGP card which ran great and guessed that even though it's onboard the 8200 would be at least comparable...I was a little upset to see a slide show when fighting 2 or more people. Confused! I check the /proc to make sure the drivers are right and working correctly.

first problem I found was SBA was disabled, first instinct was to verify that the card supports SBA. So it was a cat /prob/drivers/nvidia/agp and nothing...checked around and cards/ registry and version were there but no agp. Where's the AGP?

the board is a PCI-e but I thought that AGP was integrated with that and the drivers would still use an AGP module. dmesg shows no AGP whatsoever and Xorg.0.log only shows that the "Use of NVIDIA internal AGP requested"

Looking at the registry for the drivers I see that NvAGP is set to 3 which is to use no module while I have xorg set to use 1 and the log appears to attempt that.

I'm stumped! this isn't what was expected. Where'd my AGP go? Would using the kernel's AGP rather then nvidia's be recommended here?

[bwkaz]

NvAGP is no longer (?) an option in the Xorg configuration. It's now a parameter to the kernel module. I have this in /etc/modprobe.conf, with a PCIe (x16) card:

options nvidia NVreg_EnableAGPSBA=1 NVreg_EnableAGPFW=1 NVreg_NvAGP=1 NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=12 NVreg_DeviceFileMode=0660 and /proc/driver/nvidia/registry shows:

NvAGP: 1
ReqAGPRate: 15
EnableAGPSBA: 1
EnableAGPFW: 1 (among the other less useful values). I have no NvAGP option in xorg.conf at all -- and it may even be that having a conflicting option in there prevents any kind of acceleration, though that would be somewhat surprising.

However, given the 8200 model number, it's possible that this is one of the really cheap (aka really really crappy) cards. I remember when they introduced the 5200 series, and they were getting outperformed by GF3 type cards from N years before that. The 6200s seemed to follow this tradition (getting outperformed by mid-range cards from two generations before); it's possible that the 8200s did as well.

[DanceMan]

The 8200 is the latest Nvidia integrated video motherboard chipset for AMD cpus, equivalent to the AMD 780G.

Icarus -- which distro are you using with that, and 32 or 64-bit? I have the Gigabyte version and had booting issues with the 64-bit versions.

[Icarus]

Using 32bit, I was pretty disappointed when i tried the 64bit.

Ya, the 8200 is pretty bad but I can't believe they are this bad. Can't even run youtube with out a pause every other second. Non-accelerated graphics can handle that...even under linux ;)

I'll try those options bwkaz and see if there is any improvement, can't get any worse.
The end all will be Thursday when I get my new 9800 GTX, if I still have problems with that I think I'll just give up on computers :D

[Icarus]

That did help bwkaz, both SBA and FW are enabled now. I had to change the device permissions, for some reason the /dev/nvidia* was set for the mail group originally...

At least now Savage2 runs at a tolerable pace...it only slide shows now when 30 people are banging on a lair/stronghold :D

Firefox/Flash is still horribly awfully ungodly slow for some reason though.

[bwkaz]

Mail group?

Oh, I bet I know. The DeviceFileUID / DeviceFileGID were in the line I posted. I should have specified; those were specific to my system. (UID 0 is always root, but gid 12 is only going to be video on my system. It would be nice if those values could be user and group names, but the module doesn't let you do that, likely because it can't resolve those names from inside the kernel.

Just use whatever GID your distro's video group (or other applicable group) has. You probably have already. :)

(Actually, you might not need that at all. If your X server is setuid-root, and the X server is the only thing that talks to the device file, then this should be fine. I haven't tried it; I've always assumed libGL needed to talk to the device file too.)

Firefox/Flash is still horribly awfully ungodly slow for some reason though. Because it's Flash? :p

Nah, I'll try to be at least slightly helpful. ;) What version? Versions before 9 were really really slow, and 10 supposedly helps with the CPU usage a bit. Might be worth a shot if you're still using something old.

[Icarus]

Ya, i figured out that group problem, in Gentoo it's GID=27 ;)

We all know Flash is horribly slow and terrible on Linux :p
I am using 10.0.15.3 and am still waiting for them not to lie about the performance improvements they keep claiming with every update :D
Overall Flash is running alright now but it seems overly CPU bound and heavy, I wonder if the dual core is causing any issues with it? I also wonder if I even have dual core support enabled right, proc/cpuinfo only shows one processor...unless they have changed that in the last couple years on me also!
Welcome to the 21st century Steve, now adapt or die! :p

[bwkaz]

Well, /proc/cpuinfo is obviously from the kernel. I'm running a dual-core and kernel 2.6.27.8; my /proc/cpuinfo definitely does show two CPUs. (This also matches my experience with multi-core systems elsewhere: each core shows up as a CPU in /proc/cpuinfo.) Of course, this kernel is a version or two old now, but I don't think that has changed.

Do you have the SMP options turned on in the kernel? If so, are you passing maxcpus=1 or maxcpus=0 or nosmp on the kernel command line? Alternately, are you disabling the IO-APIC? (I'm pretty sure the IO-APIC is required for SMP support, to handle IRQs properly across more than one CPU. ACPI may not be required, but that's different. :))

I'm running an older plugin (9.something); I really need to update it, but that's beside the point. It's fast enough (most of the time), and I know I have more than one core enabled. ;)

[Icarus]

Actually I'm pretty sure I don't have SMP enabled...pretty much kept the same kernel except changed the processor type from Athlon to Athlon64...I'll have to recompile that.
As for passing options I tend not to do that unless I have to, I usually try to compile that all into the kernel just to keep things cleaner. Considering it looks like a lot of my problems now are from the CPU getting maxed and hard drive usage, but HD is always a problem :D