Window drag lag with GeForce GTX 750, cinnamon, gnome, unity

I have this PC configuration:
Asus P8B75-V motherboard,
Intel core i5-2320,
Asus GeForce GTX 750 OC,
8GB RAM.

I bought that graphic card couple days ago.
As you can see the computer is prety good configuration, and i have problems with almost every desktop environment. When i drag windows around, it lags begind mouse pointer. It happens in unity, cinnamon, gnome 3. In windows i play some games at 1080p, so i would say hardware is not the matter here.

Last i tried gnome 3, and switched to integrated graphics just to check and didn’t have the lag. Changed back to geforce, it comes back. Tried almost every available proprietary driver, 340, 343, 346, 352… Nouveau isn’t the option also. Is there anything i could do or try to fix this? :(

I am heavy linux user, and this is just frustrating. I do all my work in linux.

Here is the video of the issue, if you paused in some moments you will see it very clearly.

Greets, Cvetan

https://devtalk.nvidia.com/default/topic/522835/linux/if-you-have-a-problem-please-read-this-first/

When i ran command, i got this output

nvidia-bug-report.sh will now collect information about your
system and create the file 'nvidia-bug-report.log.gz' in the current
directory.  It may take several seconds to run.  In some
cases, it may hang trying to capture data generated dynamically
by the Linux kernel and/or the NVIDIA kernel module.  While
the bug report log file will be incomplete if this happens, it
may still contain enough data to diagnose your problem.

Please include the 'nvidia-bug-report.log.gz' log file when reporting
your bug via the NVIDIA Linux forum (see devtalk.nvidia.com)
or by sending email to 'linux-bugs@nvidia.com'.

Running nvidia-bug-report.sh...Failed to look up boot -1: Cannot assign requested address
Failed to look up boot -2: Cannot assign requested address


If the bug report script hangs after this point consider running with
--safe-mode command line argument.

And here is the report.

nvidia-bug-report.log.gz (135 KB)

I think all repaint issues boil down to this:
https://devtalk.nvidia.com/default/topic/729908/linux/-gt-334-21-redrawing-problems-in-gnome-3-10-3-12-gtx-580/6/

Doesn’t look the same issue as i wrote here. Sorry if don’t undestand well, but i don’t have those kind of lags on my computer.

Just this which i posted in my video. :(

I see miner stuttering not huge lag/delay in window movement. Can you please test with Nouveau ? Also share video recording for Nouveau and integrated graphics graphics?

That is when i recorded in unity. In gnome shell and cinnamon is much more obvious, and unbearable. Even if i move window very slowly.

Nouveau is not option at all, since i have much tearing, and can’t get full resolution.

Pause the video couple times, you will see how much window lates behind cursor. I will record gnome desktop as soon as i come home.

Here are the videos for nvidia, nouveau and integrated graphics.

You will see that the best performance is with integrated graphics, but not perfect. There is still some lag. nvidia horrible, nouveao little better. :(

Is it any different if you lock the card to the highest performance level in the nvidia settings panel?

No it isn’t. It is the same.

Do i need to reboot to apply maximum performance? Because nvidia settings are lost at reboot, although i’ve tried setting this option.

I have this behavior on my GTX 580 on Gnome, too. For quite a while (basically forever), but I always just blamed it on Xorg being crap. On your video nouveau is also pretty bad with the mouse cursor lag while Intel isn’t. I think that could be, because the Intel driver supports DRI3 with Xorg while nouveau doesn’t iirc. If you launch Gnome on Wayland with nouveau your cursor will stay exactly on the same pixel where you grabbed the window no matter how fast you move around. This makes Gnome on Wayland with nouveau feel much better and more direct than Gnome with the NVIDIA driver. The only problem is that with nouveau your GPU never reclocks to higher performance to make the animations smooth when you hit the super key etc.

How come KDE, XFCE don’t have this problem?

In truth XFCE does have tearing by default but that’s fixable. And KDE just doesn’t suit me, so i can’t use it.

XFCE doesn’t have a compositor by default. And Kwin is broken with NVIDIA last time I used it:
https://bugs.kde.org/show_bug.cgi?id=322060

That would be my guess.

XFCE does have compostior since 4.2 version, although it is very poor.

And i didn’t have issues with KDE.

I don’t think it’s an OpenGL compositor though. It does compositing on the CPU.
Kwin is broken for me with NVIDIA, which means it doesn’t even composite a real image. Gnome is the only thing that does actual compositing how it should be (meaning no tearing or artifacts).

Don’t get me wrong, i don’t like KDE but as i said i didn’t have issues with it. Not on my integrated graphics, not with the old entry level Radeon card.

Basically i have trouble with everything after Ubuntu 12.04. That’s more than two years.

I always preffered nVidia over radeon, but for the last few days i am verydissapointed. Would this bug be unsolved for this log, if it affected windows for example? Generally hardware manufacturers don’t pay much attention to Linux, and that it sorrow truth. :(

I personally don’t have any problems in Unity (on a GTX 570), so it seems feasible. I would expect issues with gnome3 and cinnamon because they’re both trainwrecks in terms of underlying technology.

That’s pretty rich coming from someone who uses a desktop that is built on Compiz.

How do i set maximum performance in xorg.conf?

Since setting is lost after reboot.

Edit:
Found it.

Edit #2:
I entered
Option “RegistryDwords” “PowerMizerEnable=0x1; PerfLevelSrc=0x2222; PowerMizerDefaultAC=0x1”

in device section in /etx/X11/xorg.conf, but it doesn’t persist reboot/logout.

This lag is because the nvidia driver defers the buffer swap nearly forever, and longer with triple buffering enabled.

If you’re a developer, you can force it to keep up by using a glFinish call or setting a sync fence to wait until the front framebuffer is updated, which is the equivalent of what open drivers do.

Gnome does nothing to help, its developers will merely shun you for using closed drivers.

Compiz has an option somewhere to work around this.

KDE tries to be smart. It generally works properly, but sometimes doesn’t do so well.

Windows apparently has an option, something like “maximum prerendered frames” that might be an appropriate fix if we had it on the unix drivers.