[Bug 1037411] Re: [regression][DRI] SubBuffer rendering is much slower in compiz 0.9.8.0 than it was in 0.9.7
** Changed in: mesa (Ubuntu) Status: Triaged => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1037411 Title: [regression][DRI] SubBuffer rendering is much slower in compiz 0.9.8.0 than it was in 0.9.7 To manage notifications about this bug go to: https://bugs.launchpad.net/compiz/+bug/1037411/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1037411] Re: [regression][DRI] SubBuffer rendering is much slower in compiz 0.9.8.0 than it was in 0.9.7
** Changed in: mesa Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1037411 Title: [regression][DRI] SubBuffer rendering is much slower in compiz 0.9.8.0 than it was in 0.9.7 To manage notifications about this bug go to: https://bugs.launchpad.net/compiz/+bug/1037411/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1037411] Re: [regression][DRI] SubBuffer rendering is much slower in compiz 0.9.8.0 than it was in 0.9.7
quantal has seen the end of its life and is no longer receiving any updates. Marking the quantal task for this ticket as Won't Fix. ** Changed in: mesa (Ubuntu Quantal) Status: Triaged = Won't Fix -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1037411 Title: [regression][DRI] SubBuffer rendering is much slower in compiz 0.9.8.0 than it was in 0.9.7 To manage notifications about this bug go to: https://bugs.launchpad.net/compiz/+bug/1037411/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1037411] Re: [regression][DRI] SubBuffer rendering is much slower in compiz 0.9.8.0 than it was in 0.9.7
** Changed in: compiz Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1037411 Title: [regression][DRI] SubBuffer rendering is much slower in compiz 0.9.8.0 than it was in 0.9.7 To manage notifications about this bug go to: https://bugs.launchpad.net/compiz/+bug/1037411/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1037411] Re: [regression][DRI] SubBuffer rendering is much slower in compiz 0.9.8.0 than it was in 0.9.7
This bug was fixed in the package compiz - 1:0.9.8.2+bzr3377-0ubuntu1 --- compiz (1:0.9.8.2+bzr3377-0ubuntu1) quantal-proposed; urgency=low [ Sam Spilsbury ] * debian/python-compizconfig.install - Install compizconfig-python.pc * debian/patches/100_expo_layout.patch - re-add the expo layout that used to be in precise (LP: #1047067) - add some testcases [ Timo Jyrinki ] * New upstream snapshot. - Fix multiple window placement bugs (LP: #974242) (LP: #976032) - Don't waste CPU looping through and looking at all the windows if you're rendering an output that has no damage on it. (LP: #1014986) - Updated convert files to fix some typos in the key names. (LP: #1041631) - Fix crash when imgsvg is loaded, due to missing symbol (decor_apply_gravity from libdecoration). (LP: #956986) - Treat unresolved symbols at link time as an error, rather than letting them through and cause strange crashes later. (LP: #1043143) - Refactors a little bit of the upgrade code and gets it under test to prepare to fix (LP: #1042537) - Updated AUTHORS from the full bzr log, and re-sort the list. (LP: #1042095) - Fixes FTBFS for kde4-window-decorator (LP: #1041310) - Fix obvious omissions from the introduction of unminimize_*, which were causing the unminimize animation settings to be ignored (LP: #1040455) - resize plugin: don't crash if resize wasn't initiated externally (LP: #1045191) - Clean up capitalization (LP: #1045652) - Avoid division by zero, if plugins try to deform a window down to size zero. (LP: #1045235) - Make Unredirect Fullscreen Windows more reliable. This fixes the problem with unredirection failing to engage at all (LP: #1041066) when gtk-window-decorator creates offscreen windows that are stacked on top. This also fixes the problem with unredirect hiding all windows, because it thinks the desktop window should be stacked on top (LP: #980663). - Ensure unredirected windows don't stay unredirected if they're no longer on top. (LP: #1041047) - Fix launching terminal functionality and make show-hud default key visible. Update the defaults to org.compiz.integrated to reflect the actual gnome values pre-gnome-3. (LP: #1040081) (LP: #1046199) (LP: #1046190) - Fix show-hud, bump COMPIZ_GNOME_INTEGRATED_SETTINGS_LIST_SIZE. (LP: #1046212) - Fixed: Windows with an alpha-channel, like gnome-terminal, were not being considered as possibly covering fullscreen windows. But they most certainly can. This ensures such RGBA windows are visible if they're stacked above a fullscreen window. (LP: #1046661) - Remove ListToStringList (LP: #1046184) - Fix typo causing CMake Error (LP: #1045665) - Transitions gtk-window-decorator over to use GSettings. Add a testing framework for the options code. (LP: #1042323) - Also need kdeworkspace since kdecorationbridge.h is there (LP: #1046770) - Implements some cleanup that was suggested on the merge for the original port to gsettings. Other issues fixed as well. (LP: #1042323) - Fix the case where a new gsettings schema got added for building but it wasn't recompiled locally (LP: #1046701) - Scale: select the window under the pointer, when the scale animation is over. (LP: #1045127) - Fixes the some Use of uninitialised value warnings reported by valgrind (LP: #1004336)) - Check if org.gnome.mutter is available before using it (LP: #1048551) - We don't need to map our style windows, prevent them from cluttering up the paint queue (LP: #1042552) - Migrate profile independent keys separately from the profile dependent keys (LP: #1046190) - Don't ever enter the subdir of a plugin that is disabled. (LP: #1049100) - Workaround SubBuffer performance regression (LP: #1037411) - Changed the default placement of the benchmark window from 0,0 to 100,50. (LP: #1039406) - Ensure window decorations always get rendered after the window, not before. This is how it was in compiz 0.9.7, and is required in order to resolve unity panel shadow (LP: #1050704) - Fix CMakeLists.txt to bring an xslt file back to compiz-dev - Avoid a NULL dereference and give a useful error message instead (LP: #944653) - Fix (LP: #1050752) - Check that pixmaps which aren't managed by us actually exist before binding. (LP: #927168) - Fix flickering and performance problems with using Unredirect Fullscreen Windows with multiple monitors. (LP: #1050749) (LP: #1051885) * debian/compiz-dev.install - Remove compizconfig-python.pc, now in python-compizconfig.install * Drop dependency on libgconf2-dev, add gconf2 dependency to the transitional package for migrations * Add -DUSE_GCONF=OFF to debian/rules *
[Bug 1037411] Re: [regression][DRI] SubBuffer rendering is much slower in compiz 0.9.8.0 than it was in 0.9.7
Launchpad has imported 8 comments from the remote bug at
https://bugs.freedesktop.org/show_bug.cgi?id=54763.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
On 2012-09-11T09:24:50+00:00 Daniel van Vugt wrote:
I call glCopyPixels a couple of times briefly on startup and then never
again. The problem is that doing this makes all subsequent rendering
much slower. If I never call glCopyPixels on startup then rendering
remains fast thereafter.
It seems glCopyPixels is modifying the context in a way that permanently
cripples later operations. The only possible cause I can see so far is:
src/mesa/main/drawpix.c: _mesa_CopyPixels:
/* We're not using the current vertex program, and the driver may install
* it's own. Note: this may dirty some state.
*/
_mesa_set_vp_override(ctx, GL_TRUE);
This seems to set a flag in the ctx which is never cleared.
Using Mesa 8.0.2 in Ubuntu 12.04
Reply at: https://bugs.launchpad.net/compiz/+bug/1037411/comments/16
On 2012-09-11T10:10:48+00:00 Daniel van Vugt wrote:
I am using Intel Sandy Bridge HD 2000 by the way. I believe that means
i965.
Reply at: https://bugs.launchpad.net/compiz/+bug/1037411/comments/18
On 2012-09-11T13:32:24+00:00 Michel-daenzer wrote:
(In reply to comment #2)
I call glCopyPixels a couple of times briefly on startup and then never again.
The problem is that doing this makes all subsequent rendering much slower. If
I
never call glCopyPixels on startup then rendering remains fast thereafter.
What are the read and draw buffers for glCopyPixels? If either of them
is GL_FRONT*, that will cause a DRI2 fake front buffer to be allocated
and thereafter kept up to date wrt the real front buffer.
This seems to set a flag in the ctx which is never cleared.
It is cleared:
end:
_mesa_set_vp_override(ctx, GL_FALSE);
Reply at: https://bugs.launchpad.net/compiz/+bug/1037411/comments/19
On 2012-09-12T01:48:54+00:00 Daniel van Vugt wrote:
Yes, the read buffer is GL_FRONT in this case. So I guess the slow-down
is by design in Mesa. I'm going to work around it in compiz anyway.
glCopyPixels should never be touched at all really.
P.S. _mesa_set_vp_override(ctx, GL_FALSE) does not clear NewState. Which
is what I was concerned about:
void
_mesa_set_vp_override(struct gl_context *ctx, GLboolean flag)
{
if (ctx-VertexProgram._Overriden != flag) {
ctx-VertexProgram._Overriden = flag;
/* Set one of the bits which will trigger fragment program
* regeneration:
*/
ctx-NewState |= _NEW_PROGRAM;
}
}
Reply at: https://bugs.launchpad.net/compiz/+bug/1037411/comments/20
On 2012-09-12T02:33:00+00:00 Marek Olšák wrote:
Don't worry about NewState. It's cleared after every draw operation.
Reply at: https://bugs.launchpad.net/compiz/+bug/1037411/comments/21
On 2012-09-12T04:52:06+00:00 Chris Forbes wrote:
Would it be reasonable to put a performance note in
ARB_debug_output/KHR_debug when mesa falls into this slow state?
Reply at: https://bugs.launchpad.net/compiz/+bug/1037411/comments/22
On 2012-09-12T09:29:28+00:00 Michel-daenzer wrote:
(In reply to comment #3)
Yes, the read buffer is GL_FRONT in this case. So I guess the slow-down is by
design in Mesa.
Rather the X server / DRI2 protocol. It *might* be possible to make
xserver not enforce the fake front buffer for the Composite Overlay
Window, not sure.
I'm going to work around it in compiz anyway. glCopyPixels
should never be touched at all really.
Out of curiosity, what are you using it for?
Reply at: https://bugs.launchpad.net/compiz/+bug/1037411/comments/23
On 2012-09-12T09:31:58+00:00 Daniel van Vugt wrote:
It is a fallback used for maintaining a persistent backbuffer if FBOs
are not available. However it's not an important one because all drivers
provide FBOs now.
http://bazaar.launchpad.net/~compiz-
team/compiz/0.9.8/view/head:/plugins/opengl/src/screen.cpp#L1726
Reply at: https://bugs.launchpad.net/compiz/+bug/1037411/comments/24
** Changed in: mesa
Status: Unknown = Confirmed
** Changed in: mesa
Importance: Unknown = Medium
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1037411
[Bug 1037411] Re: [regression][DRI] SubBuffer rendering is much slower in compiz 0.9.8.0 than it was in 0.9.7
Fix committed into lp:compiz at revision 3370 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1037411 Title: [regression][DRI] SubBuffer rendering is much slower in compiz 0.9.8.0 than it was in 0.9.7 To manage notifications about this bug go to: https://bugs.launchpad.net/compiz/+bug/1037411/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1037411] Re: [regression][DRI] SubBuffer rendering is much slower in compiz 0.9.8.0 than it was in 0.9.7
** Changed in: compiz Status: In Progress = Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1037411 Title: [regression][DRI] SubBuffer rendering is much slower in compiz 0.9.8.0 than it was in 0.9.7 To manage notifications about this bug go to: https://bugs.launchpad.net/compiz/+bug/1037411/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1037411] Re: [regression][DRI] SubBuffer rendering is much slower in compiz 0.9.8.0 than it was in 0.9.7
** Summary changed: - [regression][GLES] SubBuffer rendering is much slower in compiz 0.9.8.0 than it was in 0.9.7 + [regression][DRI] SubBuffer rendering is much slower in compiz 0.9.8.0 than it was in 0.9.7 ** Branch linked: lp:~vanvugt/compiz/fix-1037411 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1037411 Title: [regression][DRI] SubBuffer rendering is much slower in compiz 0.9.8.0 than it was in 0.9.7 To manage notifications about this bug go to: https://bugs.launchpad.net/compiz/+bug/1037411/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1037411] Re: [regression][DRI] SubBuffer rendering is much slower in compiz 0.9.8.0 than it was in 0.9.7
** Also affects: mesa (Ubuntu Precise) Importance: Undecided Status: New ** Also affects: compiz (Ubuntu Precise) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1037411 Title: [regression][DRI] SubBuffer rendering is much slower in compiz 0.9.8.0 than it was in 0.9.7 To manage notifications about this bug go to: https://bugs.launchpad.net/compiz/+bug/1037411/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1037411] Re: [regression][DRI] SubBuffer rendering is much slower in compiz 0.9.8.0 than it was in 0.9.7
** Changed in: compiz (Ubuntu Precise) Status: New = Invalid ** Changed in: mesa (Ubuntu Precise) Status: New = Invalid ** Changed in: mesa (Ubuntu Quantal) Status: New = Triaged -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1037411 Title: [regression][DRI] SubBuffer rendering is much slower in compiz 0.9.8.0 than it was in 0.9.7 To manage notifications about this bug go to: https://bugs.launchpad.net/compiz/+bug/1037411/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1037411] Re: [regression][DRI] SubBuffer rendering is much slower in compiz 0.9.8.0 than it was in 0.9.7
** Description changed: (This is no longer the primary performance regression bug for compiz 0.9.8.0. Look at bug 1024304 instead) - Comparing graphics performance in a two-monitor configuration, I find - the gles2 branch is 25-40% slower than trunk. + TEST CASE: + 1. CCSM OpenGL + framebuffer_object = OFF + vertex_buffer_object = OFF + always_swap_buffers = OFF + 2. Run graphics benchmarks. + + Expected: Similar results to compiz 0.9.7 + Observed: Much lower results than compiz 0.9.7 + + + ORIGINAL DESCRIPTION: + 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: framebuffer_object, vertex_buffer_object, always_swap_buffers So both branches should be using the same code path. But gles2 is still dramatically slower than trunk using two monitors. The good news is that this bug only affects benchmark results and seemingly a little lag. The physical frame rate achieved with two monitors still seems to be higher using the gles2 branch, meaning it drops from 60Hz to 30Hz much less often than trunk does. NOTE 1: This regression was allowed in compiz 0.9.8.0 because it is generally only visible in benchmark results. Meanwhile, physical compiz rendering performance (as reported by the compiz Benchmark plugin) is higher in compiz 0.9.8.0 than previous versions, in most cases. NOTE 2: If you're just worried about fullscreen game performance, then you don't need to wait for this bug to be resolved. You can get optimal graphics performance with unredirect mode. But see bug 980663 first. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1037411 Title: [regression][DRI] SubBuffer rendering is much slower in compiz 0.9.8.0 than it was in 0.9.7 To manage notifications about this bug go to: https://bugs.launchpad.net/compiz/+bug/1037411/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
