NVIDIA and Nouveau drivers jerky graphics and slow Xorg in 12.10

[FrankKubuntu]

I tried removing all effects one by one but no change. I'll try removing them all but the animated cube, see if it does anything. I've already tried the animated cube removed alone and no change.

So it could be something using xorg which in turn would use up cpu?

The .xession-errors file doesn't show anything out of the ordinary for me, I'm not used to read that file though. It's 66k and I'd say at least half of it is related to icon theme errors I am aware of, pulseaudio which I have uninstalled/disabled in order to use S/PDIF pass through and nepomuk/virtuoso. Tomorrow I will restore my image right after the install (fresh out of the DVD + nvidia drivers in) and see if I get the jerkiness again, but if my memory is good I was having the same problem.

A few lines caught my attention by coming back very often in that file:

QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.

Running Mixer_Backend destructor

Running Mixer_ALSA destructor

This one is there once but the word "instability" kept me focused on that line for a while lolll:

plasma-desktop(2535)/libplasma Plasma::isPluginVersionCompatible: unversioned plugin detected, may result in instability

This is what is logged for my card:

OpenGL vendor string:                   NVIDIA Corporation
OpenGL renderer string:                 GeForce 8600 GT/PCIe/SSE2
OpenGL version string:                  3.3.0 NVIDIA 313.09
OpenGL shading language version string: 3.30 NVIDIA via Cg compiler
Driver:                                 NVIDIA
Driver version:                         313.9
GPU class:                              G80/G90
OpenGL version:                         3.3
GLSL version:                           3.30
X server version:                       1.13.1
Linux kernel version:                   3.5
Direct rendering:                       yes
Requires strict binding:                no
GLSL shaders:                           yes
Texture NPOT support:                   yes

Same thing I have on 11.10, except of course the driver and xserver versions.

But you know what? On my 11.10 which is perfect for effects, after 1h45mins of usage (boot up and use it for 1h45mins) my file tops up 1.8megs. Not sure if it's normal, I see tons of errors for nepomuk, but anyway that's not on the 12.10 installation. That being said if I compare with 11.10, my 12.10 error file looks pretty clean.

[bamyasi]

You may want to check this thread:

http://www.kubuntuforums.net/showthr...rs-for-Quantal

In essence, it might be caused by a hardware/kernel driver issues (malfunctioning USB 2.0 in my case) not directly related to the graphics card and/or graphics drivers.

[FrankKubuntu]

Hi, tnx for that.

I tried those things, krandrrc wasn't there so I did not delete it. loll

I did this:

$ dmesg | grep irq
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] nr_irqs_gsi: 40
[    0.000000] NR_IRQS:16640 nr_irqs:712 16
[    0.174546] pnp 00:03: [irq 8]
[    0.174601] pnp 00:05: [irq 13]
[    0.175202] pnp 00:09: [irq 4]
[    0.175360] pnp 00:0b: [irq 1]
[    0.208072] pcieport 0000:00:01.0: irq 40 for MSI/MSI-X
[    0.208136] pcieport 0000:00:1c.0: irq 41 for MSI/MSI-X
[    0.208214] pcieport 0000:00:1c.4: irq 42 for MSI/MSI-X
[    0.231659] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    0.252965] 00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    0.255171] ahci 0000:00:1f.2: irq 43 for MSI/MSI-X
[    0.292773] ata1: SATA max UDMA/133 abar m2048@0xf9ffe800 port 0xf9ffe900 irq 43
[    0.292775] ata2: SATA max UDMA/133 abar m2048@0xf9ffe800 port 0xf9ffe980 irq 43
[    0.292777] ata3: SATA max UDMA/133 abar m2048@0xf9ffe800 port 0xf9ffea00 irq 43
[    0.292779] ata4: SATA max UDMA/133 abar m2048@0xf9ffe800 port 0xf9ffea80 irq 43
[    0.292781] ata5: SATA max UDMA/133 abar m2048@0xf9ffe800 port 0xf9ffeb00 irq 43
[    0.292783] ata6: SATA max UDMA/133 abar m2048@0xf9ffe800 port 0xf9ffeb80 irq 43
[    0.308417] ata7: SATA max UDMA/133 abar m8192@0xfeafe000 port 0xfeafe100 irq 16
[    0.308421] ata8: SATA max UDMA/133 abar m8192@0xfeafe000 port 0xfeafe180 irq 16
[    0.312786] ehci_hcd 0000:00:1a.7: irq 18, io mem 0xf9fffc00
[    0.328109] ehci_hcd 0000:00:1d.7: irq 23, io mem 0xf9fff800
[    0.340240] uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000b800
[    0.340447] uhci_hcd 0000:00:1a.1: irq 21, io base 0x0000b880
[    0.340619] uhci_hcd 0000:00:1a.2: irq 18, io base 0x0000bc00
[    0.340795] uhci_hcd 0000:00:1d.0: irq 23, io base 0x0000b080
[    0.340975] uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000b400
[    0.341147] uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000b480
[    0.341361] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
[    0.341831] serio: i8042 KBD port at 0x60,0x64 irq 1
[    0.342113] rtc0: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
[    2.598080] ata9: PATA max UDMA/100 cmd 0xdc00 ctl 0xd880 bmdma 0xd400 irq 17
[    2.598082] ata10: PATA max UDMA/100 cmd 0xd800 ctl 0xd480 bmdma 0xd408 irq 17
[   18.181932] snd_hda_intel 0000:00:1b.0: irq 44 for MSI/MSI-X

Nothing suspicious to me, but I am an a**hole to understand if there is or not something wrong in the above. loll

Then I tried:

$ dmesg | grep 'irq 16'
[    0.308417] ata7: SATA max UDMA/133 abar m8192@0xfeafe000 port 0xfeafe100 irq 16
[    0.308421] ata8: SATA max UDMA/133 abar m8192@0xfeafe000 port 0xfeafe180 irq 16
[    0.340240] uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000b800

So I tried your nvidia.conf anyway.

After I rebooted I get this:

$ dmesg | grep 'irq 16'
[    0.312411] ata7: SATA max UDMA/133 abar m8192@0xfeafe000 port 0xfeafe100 irq 16
[    0.312414] ata8: SATA max UDMA/133 abar m8192@0xfeafe000 port 0xfeafe180 irq 16
[    0.344257] uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000b800

$ dmesg | grep irq
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] nr_irqs_gsi: 40
[    0.000000] NR_IRQS:16640 nr_irqs:712 16
[    0.178540] pnp 00:03: [irq 8]
[    0.178595] pnp 00:05: [irq 13]
[    0.179197] pnp 00:09: [irq 4]
[    0.179355] pnp 00:0b: [irq 1]
[    0.212072] pcieport 0000:00:01.0: irq 40 for MSI/MSI-X
[    0.212139] pcieport 0000:00:1c.0: irq 41 for MSI/MSI-X
[    0.212214] pcieport 0000:00:1c.4: irq 42 for MSI/MSI-X
[    0.235659] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    0.256946] 00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    0.259144] ahci 0000:00:1f.2: irq 43 for MSI/MSI-X
[    0.296777] ata1: SATA max UDMA/133 abar m2048@0xf9ffe800 port 0xf9ffe900 irq 43
[    0.296780] ata2: SATA max UDMA/133 abar m2048@0xf9ffe800 port 0xf9ffe980 irq 43
[    0.296782] ata3: SATA max UDMA/133 abar m2048@0xf9ffe800 port 0xf9ffea00 irq 43
[    0.296784] ata4: SATA max UDMA/133 abar m2048@0xf9ffe800 port 0xf9ffea80 irq 43
[    0.296785] ata5: SATA max UDMA/133 abar m2048@0xf9ffe800 port 0xf9ffeb00 irq 43
[    0.296787] ata6: SATA max UDMA/133 abar m2048@0xf9ffe800 port 0xf9ffeb80 irq 43
[    0.312411] ata7: SATA max UDMA/133 abar m8192@0xfeafe000 port 0xfeafe100 irq 16
[    0.312414] ata8: SATA max UDMA/133 abar m8192@0xfeafe000 port 0xfeafe180 irq 16
[    0.316778] ehci_hcd 0000:00:1a.7: irq 18, io mem 0xf9fffc00
[    0.332130] ehci_hcd 0000:00:1d.7: irq 23, io mem 0xf9fff800
[    0.344257] uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000b800
[    0.344451] uhci_hcd 0000:00:1a.1: irq 21, io base 0x0000b880
[    0.344629] uhci_hcd 0000:00:1a.2: irq 18, io base 0x0000bc00
[    0.344809] uhci_hcd 0000:00:1d.0: irq 23, io base 0x0000b080
[    0.344996] uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000b400
[    0.345173] uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000b480
[    0.345387] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
[    0.345860] serio: i8042 KBD port at 0x60,0x64 irq 1
[    0.346172] rtc0: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
[    2.624236] ata9: PATA max UDMA/100 cmd 0xdc00 ctl 0xd880 bmdma 0xd400 irq 17
[    2.624239] ata10: PATA max UDMA/100 cmd 0xd800 ctl 0xd480 bmdma 0xd408 irq 17
[   19.441456] snd_hda_intel 0000:00:1b.0: irq 44 for MSI/MSI-X
[   25.567914] nvidia 0000:01:00.0: irq 45 for MSI/MSI-X

That last line tells me I have IRQ 45 forced for the nvidia, I guess?

No change at all in performance, though.

I then removed 'Window active state transition' as suggested by someone in your thread and no change either.
I disabled 'Animations' in that same menu. No change.
Removed 'Shadows'. Same thing.
Removed 'Animations' in 'Configure Oxygen', no change.
Tried various possibilities in 'Graphical Effects' of 'Style', no change.
Changed 'Scale method' in Desktop Effects, no change.
Removed 'OpenGL 2 shaders'. No change.
Removed 'VSync', ha, I saw a change! Subtil... Xorg uses a few % less cpu with VSync off. BUT, the hesitating animations are still there. Which seems to tell me the problem is not the fact Xorg uses more or less cpu, but something else. I tried without any effects (maybe it disables openGL) and xorg uses the same amount of cpu when I perform my actions! Like switching desktop or clicking on background windows to bring them to front, the cpu usage is the same. Of course I get no hesitation cuz there are no animations.

Like I said, don't get me wrong, the system is very usable and a 'normal' person probably wouldn't see the hesitations, but I do cuz I've got a hell of an eye to detect visual stuff and unfortunately it bothers me quite a lot (the hesitations, not the fact I got a hell of an eye to detect them loll). Usually it's when the animation starts, there is a very slight hesitation and the time it takes to hesitate ends in skipped frames to catch up that time so that the animation can end at the set time (say 1000ms for switching desktop, if it hesitates 100ms it will only animate 900ms and skip 100ms of frames). And it's not all the time, but very most of the time when I have windows opened and almost never, if not never, when I have no windows opened. I get no crashes and no instabilities other than this hesitation.

Interestingly, I used to get 5.30s in gtkperf and tonight after those changes (for which only the nvidia.conf seems permanent) I get 6.20sec. Unless I forgot something somewhere. Overall the graphical perf is the same to my eyes, though.


But now that I have seen xorg cpu usage is the same with and without effects and that without effects I get no hesitations, my guess is that it would be related to 3D acceleration, cuz when it's off, all is fine and when it's on, I get hesitations. Thing is all the drivers I have tried behave the same.

[SteveRiley]

We seem to see far, far fewer issues with people who have other graphics cards installed: Intel and AMD. By virtue of the fact that we see fewer issues with the other graphics adapters, I will think twice before buying another NVidia-based graphics adapter.

Funny because from what I've read and experienced, there seems to be far more problems with ATI chips than nVidia and the Intel video is totally unsuitable for high performance applications like games and in some cases even video playback.

Regarding degree of problematic-ness... let's examine one source of data: Phoronix forums. Here's today's snapshot of posts in the "Linux Graphics Drivers" section:



Given that people gripe only when things don't work, a possible conclusion is that AMD is the worst choice for Linux, and that nVidia and Intel run roughly at parity. Granted, this is highly unscientific, but ought to mean something.

[FrankKubuntu]

Could be true, but it also probably depends when the first posts started to add.

If they all started say in 2005 and since 2010 AMD and ATI are much much better, then the trend is downwards on the number of posts per day compared to nvidia which could be upwards, but I admit 30k vs 4k is quite a lot of a difference.

As said, totally unscientific but still interesting.

[Spadge]

25 and 23 viewing, compared to 6 and 7 - that's pretty current.

[FrankKubuntu]

Just to add on this.

Anything that uses openGL is slow. When I run Cairo-Dock, the openGL effects are slow. They have nothing to do with Xorg, so the problem may lie somewhere else. I do not know what else to do.

I will try a nighly build of 13.04 and see if I get the same problems. If yes I will log to developers.