| 2012-08-16 05:25:07 |
Daniel van Vugt |
bug |
|
|
added bug |
| 2012-08-21 07:27:28 |
Daniel van Vugt |
summary |
[GLES] Multimonitor graphics performance is 25-40% lower with gles2 than trunk |
[GLES] Graphics performance is 25-40% lower with gles2 than trunk |
|
| 2012-08-21 07:43:39 |
Daniel van Vugt |
compiz: assignee |
|
Daniel van Vugt (vanvugt) |
|
| 2012-08-22 10:26:29 |
Daniel van Vugt |
summary |
[GLES] Graphics performance is 25-40% lower with gles2 than trunk |
[regression][GLES] Graphics performance is 25-40% lower with gles2 than trunk |
|
| 2012-08-23 04:00:28 |
Daniel van Vugt |
compiz: milestone |
0.9.8.0 |
0.9.8.1 |
|
| 2012-08-23 04:01:06 |
Daniel van Vugt |
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 |
|
| 2012-08-30 15:25:34 |
Sebastien Bacher |
bug task added |
|
compiz (Ubuntu) |
|
| 2012-08-30 15:25:41 |
Sebastien Bacher |
compiz (Ubuntu): milestone |
|
ubuntu-12.10-beta-2 |
|
| 2012-08-30 15:25:43 |
Sebastien Bacher |
compiz (Ubuntu): importance |
Undecided |
Medium |
|
| 2012-08-30 15:25:44 |
Sebastien Bacher |
compiz (Ubuntu): status |
New |
Triaged |
|
| 2012-08-30 15:25:49 |
Sebastien Bacher |
nominated for series |
|
Ubuntu Quantal |
|
| 2012-08-30 15:25:49 |
Sebastien Bacher |
bug task added |
|
compiz (Ubuntu Quantal) |
|
| 2012-08-31 01:51:30 |
Daniel van Vugt |
compiz: assignee |
Daniel van Vugt (vanvugt) |
|
|
| 2012-09-05 02:04:10 |
Daniel van Vugt |
summary |
[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) |
|
| 2012-09-05 03:27:59 |
Daniel van Vugt |
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. |
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 the 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. |
|
| 2012-09-05 03:28:26 |
Daniel van Vugt |
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 the 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. |
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. |
|
| 2012-09-07 07:44:10 |
Philippe Escarbassière |
bug |
|
|
added subscriber Philippe Escarbassière |
| 2012-09-10 06:37:48 |
Sam Spilsbury |
compiz: milestone |
0.9.8.2 |
0.9.8.4 |
|
| 2012-09-10 10:09:48 |
Daniel van Vugt |
compiz: assignee |
|
Daniel van Vugt (vanvugt) |
|
| 2012-09-10 10:09:54 |
Daniel van Vugt |
compiz: status |
Triaged |
In Progress |
|
| 2012-09-10 10:10:01 |
Daniel van Vugt |
tags |
gles |
gles performance |
|
| 2012-09-10 16:06:36 |
Sam Spilsbury |
compiz: assignee |
Daniel van Vugt (vanvugt) |
Sam Spilsbury (smspillaz) |
|
| 2012-09-11 01:57:48 |
Daniel van Vugt |
compiz: assignee |
Sam Spilsbury (smspillaz) |
Daniel van Vugt (vanvugt) |
|
| 2012-09-11 09:27:28 |
Daniel van Vugt |
bug watch added |
|
https://bugs.freedesktop.org/show_bug.cgi?id=54763 |
|
| 2012-09-11 09:27:28 |
Daniel van Vugt |
bug task added |
|
mesa |
|
| 2012-09-11 09:27:41 |
Daniel van Vugt |
bug task added |
|
mesa (Ubuntu) |
|
| 2012-09-11 09:27:55 |
Daniel van Vugt |
nominated for series |
|
Ubuntu Precise |
|
| 2012-09-11 09:29:24 |
Daniel van Vugt |
summary |
[regression][GLES] Benchmark results are 15-40% lower with the gles2 code (compiz 0.9.8.0) |
[regression][GLES] SubBuffer rendering is much slower in compiz 0.9.8.0 than it was in 0.9.7 |
|
| 2012-09-11 09:37:15 |
Daniel van Vugt |
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. |
(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.
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. |
|
| 2012-09-11 10:49:31 |
Daniel van Vugt |
summary |
[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 |
|
| 2012-09-11 10:49:40 |
Daniel van Vugt |
branch linked |
|
lp:~vanvugt/compiz/fix-1037411 |
|
| 2012-09-11 10:57:12 |
Omer Akram |
bug task added |
|
mesa (Ubuntu Precise) |
|
| 2012-09-11 10:57:12 |
Omer Akram |
bug task added |
|
compiz (Ubuntu Precise) |
|
| 2012-09-12 02:06:40 |
Daniel van Vugt |
compiz (Ubuntu Precise): status |
New |
Invalid |
|
| 2012-09-12 02:06:45 |
Daniel van Vugt |
mesa (Ubuntu Precise): status |
New |
Invalid |
|
| 2012-09-12 02:06:52 |
Daniel van Vugt |
mesa (Ubuntu Quantal): status |
New |
Triaged |
|
| 2012-09-12 03:02:52 |
Daniel van Vugt |
description |
(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.
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. |
(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 >
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. |
|
| 2012-09-13 02:14:19 |
Unity Merger |
compiz: status |
In Progress |
Fix Committed |
|
| 2012-09-14 06:38:03 |
Bug Watch Updater |
mesa: status |
Unknown |
Confirmed |
|
| 2012-09-14 06:38:03 |
Bug Watch Updater |
mesa: importance |
Unknown |
Medium |
|
| 2012-09-21 05:29:26 |
Launchpad Janitor |
compiz (Ubuntu Quantal): status |
Triaged |
Fix Released |
|
| 2012-09-28 05:13:31 |
Daniel van Vugt |
compiz: status |
Fix Committed |
Fix Released |
|
| 2014-12-05 04:57:31 |
Rolf Leggewie |
mesa (Ubuntu Quantal): status |
Triaged |
Won't Fix |
|
| 2018-03-02 23:57:25 |
Bug Watch Updater |
mesa: status |
Confirmed |
Won't Fix |
|
| 2020-05-28 09:26:07 |
Timo Aaltonen |
mesa (Ubuntu): status |
Triaged |
Invalid |
|
