[regression][DRI] SubBuffer rendering is much slower in compiz 0.9.8.0 than it was in 0.9.7
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Compiz |
Fix Released
|
Medium
|
Daniel van Vugt | ||
Mesa |
Won't Fix
|
Medium
|
|||
compiz (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Precise |
Invalid
|
Undecided
|
Unassigned | ||
Quantal |
Fix Released
|
Medium
|
Unassigned | ||
mesa (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
Precise |
Invalid
|
Undecided
|
Unassigned | ||
Quantal |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
(This is no longer the primary performance regression bug for compiz 0.9.8.0. Look at bug 1024304 instead)
TEST CASE:
1. CCSM > OpenGL >
framebuffe
vertex_
always_
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_
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.
Related branches
- jenkins (community): Approve (continuous-integration)
- Compiz Maintainers: Pending requested
-
Diff: 174 lines (+52/-9)5 files modifiedplugins/opengl/include/opengl/doublebuffer.h (+3/-1)
plugins/opengl/src/doublebuffer/src/double-buffer.cpp (+9/-1)
plugins/opengl/src/doublebuffer/tests/test-opengl-double-buffer.cpp (+27/-0)
plugins/opengl/src/privates.h (+2/-0)
plugins/opengl/src/screen.cpp (+11/-7)
summary: |
- [GLES] Graphics performance is 25-40% lower with gles2 than trunk + [regression][GLES] Graphics performance is 25-40% lower with gles2 than + trunk |
Changed in compiz: | |
milestone: | 0.9.8.0 → 0.9.8.1 |
summary: |
- [regression][GLES] Graphics performance is 25-40% lower with gles2 than - trunk + [regression][GLES] Benchmark results are 15-40% lower with the gles2 + code |
Changed in compiz (Ubuntu): | |
milestone: | none → ubuntu-12.10-beta-2 |
importance: | Undecided → Medium |
status: | New → Triaged |
Changed in compiz: | |
assignee: | Daniel van Vugt (vanvugt) → nobody |
summary: |
[regression][GLES] Benchmark results are 15-40% lower with the gles2 - code + code (compiz 0.9.8.0) |
description: | updated |
description: | updated |
Changed in compiz: | |
milestone: | 0.9.8.2 → 0.9.8.4 |
Changed in compiz: | |
assignee: | nobody → Daniel van Vugt (vanvugt) |
status: | Triaged → In Progress |
tags: | added: performance |
Changed in compiz: | |
assignee: | Sam Spilsbury (smspillaz) → Daniel van Vugt (vanvugt) |
summary: |
- [regression][GLES] SubBuffer rendering is much slower in compiz 0.9.8.0 + [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 |
description: | updated |
Changed in compiz: | |
status: | In Progress → Fix Committed |
Changed in mesa: | |
importance: | Unknown → Medium |
status: | Unknown → Confirmed |
Changed in compiz: | |
status: | Fix Committed → Fix Released |
Changed in mesa: | |
status: | Confirmed → Won't Fix |
Changed in mesa (Ubuntu): | |
status: | Triaged → Invalid |
I'm guessing there's a logic change somewhere in the gles2 code, where something previously only done per output is now done on the whole screen.
framebuffer_object comes to mind, but it's not a factor here, as mentioned above.
Maybe it's because we use triangles instead of quads now. So the number of vertices etc is 50% higher in gles2.