[nvidia] XSync usage is a massive bottlenecking factor (nvidia performance regression in Compiz 0.9.8+)

[Sam Spilsbury]

Currently our usage of XSync is very inefficient, and on drivers which likely send the command queue over the protocol, this can kill performance.

Neutering XSync usage throughout compiz had the effect of lifting framerates from 30fps to 50fps. Obviously we require synchronous operation for certain things, for example:

1) Updating clients on new window positions and stack positions if they are reparented
2) Ensuring tear-free window pixmap updates
3) Ensuring tear-free damage repair.

Doing one XSync for every event handled had a negligible performance impact (0.001 of a frame). We should look into batching all of our synchronous operations with the server into this window and avoid synchronizing the server all the time.

This also applies to other synchronous X11 operations such as XGetWindowAttributes, XGetWindowProperty and XQueryTree .

[Daniel van Vugt (vanvugt)]

smspillaz:
Does reverting r3265 solve the problem significantly?

[Sam Spilsbury (smspillaz)]

Yes, however we shouldn't do that as it is non-spec compliant and will cause a regression of bug 1016367 and potentially make bug 752445 (eg, white windows on nvidia) worse.

The best solution is to move all the code that requires a server grab into one place, and do the server grab and sync once. This is what KWin does, and its fast.

[Mentis (mentis-by)]

Is there any workaround for this problem? Even moving windows is slow :(

[Daniel van Vugt (vanvugt)]

I wonder if NVIDIA's recent fixes specifically for "Unity" are related to this bug?...
http://www.nvidia.com/object/linux-display-amd64-310.14-driver.html

[chucrute301 (chucrut1nh0)]

i will try this new driver and report here in 5 - 9 days , thxx daniel you are awesome!®

[cicoandcico (cicoandcico)]

this guy tested the new driver on QQ and a lot of video cards, but apparently nothing changed for him:

http://ubuntuforums.org/showpost.php?p=12299425&postcount=6

[Silviu C. (silviucc)]

Heya,

I'm currently using this driver but the problems with window movement are still there. On the bright(er) side, it seems that having libvdpau1 installed does not cause flash videos to show weird colors anymoreon youtube. I did, however, run into a stream that had funky colors and it just crashed on twitch.tv. Also moving the glxgears window, does not seems to incur a fps penalty.

[Florin Coras (fcoras)]

In my case, with the 310.14 drivers, window resizing, moving and some compiz plugins (wall and expo) are much faster. In fact the whole system seems to be much more responsive. I installed the drivers from xorg-edgers and my graphics card is a quadro nvs 140M.

[James Christie (james-aaron-christie)]

I also installed them via xorg-edgers. The desktop is definitely more responsive, but still somewhat sluggish. It still runs noticeably slower than my laptop with an HD3000 from intel. Game performance seems mostly unchanged.

[Florin Coras (fcoras)]

Granted. I should have also mentioned that. Although performance is much improved, it's still not, let's say, 'subjectively ideal'. And I have to concur that intel boards offer better performance since my less powerful laptop with an intel card seems more responsive than the one with an nvidia card.

[James Christie (james-aaron-christie)]

A word of warning, I just tried to downgrade via ppa-purge from xorg-edgers and it did not go well. In 12.04 and prior I could do that happily by running ppa-purge and re-installing the various packages it tried to remove since it doesn't play well with multi-arch. However it lefts a large number of packages on the system from xorg-edgers without downgrading them. So I would not suggest using it to test unless you want to do some serious packge surgery after.

[Silviu C. (silviucc)]

Well fellows, in my opinion "you're doing it wrong" regarding the "edgers" ppa. If you just want the nvidia drivers you can get them with jockey. A word of caution though. Activating the 310 beta will work but jockey might say that it failed due to a conflict with nvidia-settings. If that happens, uninstall the nvidia-settings or nvidia-settings-updates packages and then install the nvidia-settings-experimental-310 package.

Messing with the edgers ppa is just asking for trouble.

[James Christie (james-aaron-christie)]

The 310 series is not currently packages for 12.10, so I installed them via xorg-edgers. In hindsight, I should have just used the installed from the nvidia site.

[James Christie (james-aaron-christie)]

Finally tried it with the officially packaged 310 series from quantal-proposed and got the same results as with xorg-edgers.

[Daniel van Vugt (vanvugt)]

Affects Nexus 7, probably.

[Sean Feole (sfeole)]

Hey Daniel,

Thanks for tagging the nexus7.

I'm marking this confirmed since you have found a regression in the drivers. However I do have some questions:

What would be an ideal test case to measure Xsync performance??
I would like to run some numbers on the Nexus7 and post them here.

[Daniel van Vugt (vanvugt)]

Sean,

It's just a matter of application frame rates and the CPU consumption that compiz incurs (in compiz and Xorg processes). So on the Nexus maybe use glmark2-es and es2gears to look at frame rates.

A test for disabling XSync completely (which will cause bugs but be a great performance comparison) would be to write a stub XSync function and LD_PRELOAD it into compiz. I will try to do that soon.

[Silviu C. (silviucc)]

With the 310.14 nvidia drivers, unchecking "sync to vblank" in the nvidia-settings utility seems to make the problem of windows stuttering during dragging go away. It seems this option defaults to "on" in the 310 series. Looks like compiz doing v-sync and the driver doing v-sync is a bad combination.

Can anyone else with nvidia cards and the 310 series driver confirm this?

[Alistair Buxton (a-j-buxton)]

It does not make the problem go away for me: it does improve it though: instead of no screen redraws at all, the screen redraws about once every 3 seconds instead. As with vsync enabled, glxgears constantly claims that is it doing 4000 FPS. So I don't think this really fixes the problem at all, it just removes some, but not all, of the xsync calls causing the problem.

[Daniel van Vugt (vanvugt)]

Yes, I've seen the same issue with nvidia for a long time (before 310). It is horribly slow if you have vsync enabled in the driver and compiz. I suspect the reason is this bug. Nvidia appears to push lots of graphics commands through the X event queue, which no other driver does. So nvidia's hyper-sensitive to X event traffic and can slow down easily. That's the theory.

Alistair: Please note that glxgears IS doing 4000 FPS when it says so. Just like any software benchmark it's telling you the number of frames it has rendered per second. In a compositing environment this has absolutely nothing to do with the physical frame rate however. You should use the compiz Benchmark plugin to get the real physical frame rate.

[Alistair Buxton (a-j-buxton)]

Sure. I only mentioned it because I still see basically the same behaviour with vsync off, just with reduced severity. If I turn off sync in compiz and nvidia settings the performance hit in minimal, actually. But then I get really nasty tearing.

[Alistair Buxton (a-j-buxton)]

And with sync off in compiz and on in nvidia I get the same total display freeze. I don't know if nvidia is overriding compiz somehow.

[Alistair Buxton (a-j-buxton)]

Here's a quick LD_PRELOAD hack to wrap XSync. It passes through to the real XSync, but you can comment the line to make it a noop, or do whatever you want.

[Daniel van Vugt (vanvugt)]

Thanks Alistair. That's what I've been doing. However it would be more helpful to people who don't understand it to remove the call to the real XSync. Because they'd need to modify your code to really test it.

My test so far is stubxsync.c:
    int XSync(void *display, int discard) { return 0; }
and built with:
    gcc -shared -o stubxsync.so stubxsync.c
Then run with:
    env LD_PRELOAD=./stubxsync.so compiz .........

[Alistair Buxton (a-j-buxton)]

With this version, and with sync to vblank enabled in both compiz and nvidia-settings, I see the same total display freezes. I loaded the hack with both compiz and glxgears.

[Daniel van Vugt (vanvugt)]

Hmm, a complete display freeze sounds like a missing XFlush. I don't think it would be a missing glFlush because that's done implicitly when we swap buffers... Unless you have changed your Compiz OpenGL plugin settings?

Regardless, please log a new bug for the display freeze. It's too early to tell if it's related to this bug at all.

[Alistair Buxton (a-j-buxton)]

Total display freeze - until I stop dragging the window.

If you really think this is a different bug I will simply remove duplicate status from my original bug report.

[Alistair Buxton (a-j-buxton)]

Also, I haven't seen any further problems at all with the disabled XSync which seems strange... it doesn't appear to have any effect at all. I even added a fprintf to make sure it was really doing something, and it is being called. Maybe something is polling the queue instead of using XSync? Or maybe it's a problem with dynamic linking of plugins?

[Daniel van Vugt (vanvugt)]

Alistair,

Sorry; if the freeze stops when you stop dragging a window then maybe this is the right bug.

More analysis and testing is required. XSync may not be the only function affecting the event queue bottleneck on nvidia. In which case the title of the bug might change.

[Daniel van Vugt (vanvugt)]

I think this bug has become a bit vague. Sam reports a difference of 30 vs 50FPS, which I cannot reproduce with any program. He also describes multiple synchronous functions needing work without sufficient evidence that we really do need to address all of them. It's dangerous to describe a solution in the definition of a bug...

What I can reproduce easily is the problem mentioned in bug 1027211 and all the other duplicates. So I will focus on that and mark all as a duplicate of that.

If anyone has a good reason to separate this one again, please speak up here. Otherwise moving to bug 1027211.

[Daniel van Vugt (vanvugt)]

Also, for completeness I have done some profiling on the Nexus 7. Stubbing XSync for compiz provided no measurable improvement on the Nexus.