Activity log for bug #1037411

Date Who What changed Old value New value Message
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