*** This bug is a duplicate of bug 1027211 ***
https://bugs.launchpad.net/bugs/1027211
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
*** This bug is a duplicate of bug 1027211 ***
https://bugs.launchpad.net/bugs/1027211
Also, for completeness I have done some profiling on the Nexus 7.
Stubbing XSync for compiz provided no measurable improvement on the
Nexus.
--
You received this bug notification because you are a member
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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
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
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.
--
You received this
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.
** Attachment added: XSync as noop
https://bugs.launchpad.net/compiz/+bug/1049214/+attachment/3450673/+files/xsync.c
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
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
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
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.
--
You received this bug notification because you
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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1049214
Title:
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.
** Attachment added: XSync stub library for testing.
https://bugs.launchpad.net/compiz/+bug/1049214/+attachment/3450221/+files/xsync.c
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; }
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.
** Changed in: ubuntu-nexus7
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1049214
Title:
[nvidia] XSync usage is a massive bottlenecking factor (nvidia
performance
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.
--
You
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
Affects Nexus 7, probably.
** Also affects: compiz (Ubuntu)
Importance: Undecided
Status: New
** Changed in: compiz (Ubuntu)
Importance: Undecided = High
** Changed in: compiz (Ubuntu)
Status: New = Triaged
** Also affects: ubuntu-nexus7
Importance: Undecided
** Changed in: compiz
Assignee: Sam Spilsbury (smspillaz) = Daniel van Vugt (vanvugt)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1049214
Title:
[nvidia] XSync usage is a massive
** Changed in: compiz
Status: Triaged = In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1049214
Title:
[nvidia] XSync usage is a massive bottlenecking factor (nvidia
performance
20 matches
Mail list logo
