** Bug watch added: freedesktop.org Bugzilla #54763
https://bugs.freedesktop.org/show_bug.cgi?id=54763
** Also affects: mesa via
https://bugs.freedesktop.org/show_bug.cgi?id=54763
Importance: Unknown
Status: Unknown
** Also affects: mesa (Ubuntu)
Importance: Undecided
St
This is a little bit mind-bending, but I've found the problem, at least
on my precise desktop using Intel Sandy Bridge graphics...
1. I disable all the fancy new opengl rendering options so compiz should use
regional redraws, so useFbo is always false.
2. On startup, I get a couple of frames with
Sorry, my mistake.
The slowdown in r3255 is only due to using the FBO on every frame. If I
modify r3255 to use regional redraws then its still fast. So the
regression in regional redraw performance happened after r3255.
--
You received this bug notification because you are a member of compiz
pac
You could be right about glClear though. I notice that clearBuffers is
not set to false again anywhere in screen.cpp
--
You received this bug notification because you are a member of compiz
packagers, which is subscribed to compiz in Ubuntu.
https://bugs.launchpad.net/bugs/1037411
Title:
[regr
The point is that forcing the glXCopySubBufferMESA code path is still
slow after r3255. I was surprised too.
--
You received this bug notification because you are a member of compiz
packagers, which is subscribed to compiz in Ubuntu.
https://bugs.launchpad.net/bugs/1037411
Title:
[regression][
No comment, until I actually test my theories and maybe come up with
more.
--
You received this bug notification because you are a member of compiz
packagers, which is subscribed to compiz in Ubuntu.
https://bugs.launchpad.net/bugs/1037411
Title:
[regression][GLES] Benchmark results are 15-40%
I'm a little confused by that.
Changing from tmpRegion to screen->region () effectively meant that the
entire backing framebuffer object is painted to the backbuffer, rather
than a small portion of it. This is necessary because we are always
using glXSwapBuffers and the backbuffer becomes invalida
I suspect the cause is either glClear (very expensive) being called too much,
or this:
- gScreen->glPaintCompositedOutput (tmpRegion, scratchFbo, mask);
+ gScreen->glPaintCompositedOutput (screen->region (), scratchFbo, mask);
--
You received this bug notification because you are a member of com
** Changed in: compiz
Assignee: Sam Spilsbury (smspillaz) => Daniel van Vugt (vanvugt)
--
You received this bug notification because you are a member of compiz
packagers, which is subscribed to compiz in Ubuntu.
https://bugs.launchpad.net/bugs/1037411
Title:
[regression][GLES] Benchmark r
Okay, I have a half implementation of using glBlitFramebuffer, and have
some ideas as to how we might be able to preserve vsync while not using
fbo's at all (still necessary for nvidia).
In progress.
** Changed in: compiz
Assignee: Daniel van Vugt (vanvugt) => Sam Spilsbury (smspillaz)
--
Ah okay, its the fact that we draw from an fbo to the backbuffer. Seems
fair.
I'll have a look into using glBlitFramebuffer
--
You received this bug notification because you are a member of compiz
packagers, which is subscribed to compiz in Ubuntu.
https://bugs.launchpad.net/bugs/1037411
Title:
I'm pretty sure revision 3255 came from smspillaz. Though it's not
obvious.
--
You received this bug notification because you are a member of compiz
packagers, which is subscribed to compiz in Ubuntu.
https://bugs.launchpad.net/bugs/1037411
Title:
[regression][GLES] Benchmark results are 15-40
Bisected. The major cause of this regression is:
http://bazaar.launchpad.net/~compiz-linaro-team/compiz/gles2/revision/3255
--
You received this bug notification because you are a member of compiz
packagers, which is subscribed to compiz in Ubuntu.
https://bugs.launchpad.net/bugs/1037411
Title:
** Changed in: compiz
Assignee: (unassigned) => Daniel van Vugt (vanvugt)
** Changed in: compiz
Status: Triaged => In Progress
** Tags added: performance
--
You received this bug notification because you are a member of compiz
packagers, which is subscribed to compiz in Ubuntu.
http
** Changed in: compiz
Milestone: 0.9.8.2 => 0.9.8.4
--
You received this bug notification because you are a member of compiz
packagers, which is subscribed to compiz in Ubuntu.
https://bugs.launchpad.net/bugs/1037411
Title:
[regression][GLES] Benchmark results are 15-40% lower with the gle
** Description changed:
Comparing graphics performance in a two-monitor configuration, I find
the gles2 branch is 25-40% slower than trunk.
This would not normally be surprising, however the slowdown REMAINS even
when I turn off the new rendering features in the gles2 branch:
framebuf
** Summary changed:
- [regression][GLES] Benchmark results are 15-40% lower with the gles2 code
+ [regression][GLES] Benchmark results are 15-40% lower with the gles2 code
(compiz 0.9.8.0)
--
You received this bug notification because you are a member of compiz
packagers, which is subscribed to
17 matches
Mail list logo
