Issue metadata
Sign in to add a comment
|
Chrome 69 is slower rendering with hardware acceleration on
Reported by
dat...@gmail.com,
Sep 5
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.81 Safari/537.36 Steps to reproduce the problem: 1. Turn Hardware Acceleration Off in Google Chrome 2. Go to https://dev3.orgchartnow.com 3. login using the following creds: google@google.com 4. Password: tbs2rt 5. A chart will open 6. Click on the gear icon while holding down the shift key 7. Select 'Test Performance' 8. Repeat a number of times. 9. Turn Hardware Acceleration On in Google Chrome 10. Repeat steps 2-8. With Hardware Acceleration OFF performance is about 14 FPS. With Hardware Acceleration OFF performance is about 20 FPS. A 40% difference! What is the expected behavior? Hardware acceleration performance should be the same or faster. What went wrong? Chrome 69 has a performance issue with Hardware Acceleration. Did this work before? Yes Chrome 67 Chrome version: 69.0.3497.81 Channel: stable OS Version: 10.0 Flash Version: https://bugs.chromium.org/p/chromium/issues/detail?id=872117 might be related. Wasn't an issue in Chrome 67.
,
Sep 5
Comment #1 should read - With Hardware Acceleration ON performance is about 14 FPS. With Hardware Acceleration OFF performance is about 20 FPS. A 40% difference!
,
Sep 5
Bisect info: 572133 (good) - 572135 (bad) https://chromium.googlesource.com/chromium/src/+log/aec6172c..65c38f54?pretty=fuller Suspecting r572135 = 65c38f54b0ae666e8b27bfa5aef6d3ab92d4a783 = https://crrev.com/c/1105505 by jdarpinian@chromium.org "GPU: Grow and shrink transfer buffer" Landed in 69.0.3481.0
,
Sep 5
Since this has a per revision bisect and jdarphinian@ is OOO assinging to piman@ who reviewed the CL.
,
Sep 5
Thanks for the bisect! That CL may have winners and losers, but having a repro case as you provided is useful, and we should see if there's something that we can do. -> vmiura to find an owner
,
Sep 5
Attaching trace. It looks like skia is issuing a very large number of commands, and we end up filling up the command buffer, and blocking on execution on the GPU side, losing overlap. Probably what was happening before James's patch is that we would flush earlier because filling up the transfer buffer, but the autosizing removed the need for that. We can probably tune the command buffer logic to flush sooner, and/or have SkiaPaintCanvas::FlushAfterDrawIfNeeded explicitly do so.
,
Sep 6
Hi when can we expect to get a fix for this? I am experiencing the same issue exactly.
,
Sep 7
i am experiencing the same issue on a lot html5 game, please hot fix this issue.
,
Sep 7
Hi Pros, is there any update on chrome v69 hardware acceleration issue? It's affecting html5 animation as well. We have tested there were no issue in v70 & v71. Appreciate if you can release a hotfix for v69. We can't wait for v70 or v71. Or provide a solution how can we fix in our code? Thank you.
,
Sep 7
Adding "RBS" for tracking, pls remove if needed. Thank you.
,
Sep 7
,
Sep 7
Worst Release Ever
,
Sep 7
why this release version have huge amount of issues occurred especially html5 games, so disappointing.
,
Sep 7
While investigating Issue 880620 tested the URL updated in C#0 as well. Below are the observations as tested on Windows-10: =================================================== 68.0.3440.106 -- ~30 FPS 69.0.3480.0 -- ~29 FPS 69.0.3481.0 --~29 FPS 69.0.3487.0 -- ~30 FPS 69.0.3489.0 -- ~29 FPS 69.0.3491.0 -- ~24 FPS<---- 69.0.3497.81 -- ~24 FPS 71.0.3545.0 -- ~24 FPS and Below is tool bisect result: https://chromium.googlesource.com/chromium/src/+log/581b375d9bb0a4c0bd57ae14b1ed49c7976399b7..6a1536afade0b4d51f5665aa7025370331bb0c15 , which also contains 'GPU: Grow and shrink transfer buffer' by jdarpinian@ as updated in C#3. As per the test this is still an issue on M-71 canary(71.0.3545.2) and also observed by datnow@ in C#1, however C#9 suggests otherwise. azurite2018@: Could you please recheck and confirm whether the issue is resolved from your end on M-70 and M-71 and please provide the html5 animation example you are checking.
,
Sep 7
Dear Chromium Team, Thank you for taking prompt action on this and I appreciate that. I have just retested on 70 and 71 versions and I have to agree with you that the issue exists in both versions too. I hope you can take action immediately to provide fixes on this. I am sorry that I cannot provide html samples due to company policies. Thank you.
,
Sep 7
sunny, could you please debug this today?
,
Sep 7
Automatic flushes are supposed to fix this, but it looks like they're disabled for the shared main thread context (ContextType RENDERER_MAIN_THREAD seen in trace) that's used by canvas: RenderThreadImpl::SharedMainThreadContextProvider() calls RenderThreadImpl::CreateOffscreenContext() which always sets automatic_flushes to false. I'm going to experiment with enabling automatic flushes for the canvas context to see if that fixes the problem. https://cs.chromium.org/chromium/src/content/renderer/render_thread_impl.cc?l=1415&gs=kythe%253A%252F%252Fchromium%253Flang%253Dc%25252B%25252B%253Fpath%253Dsrc%252Fcontent%252Frenderer%252Frender_thread_impl.cc%25236dD2w1QnVtu%25252BT4wDmrItjjlO3BmPkTuUhR4dUtDFk88%25253D&gsn=SharedMainThreadContextProvider&ct=xref_usages
,
Sep 7
Result of quick test on my corp workstation (2560 x 1440 resolution): With automatic flush: ~21 fps Without automatic flush: ~15 fps
,
Sep 7
,
Sep 7
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f3fd321621a946f69068fa5d50dc0c9c505a6bab commit f3fd321621a946f69068fa5d50dc0c9c505a6bab Author: Sunny Sachanandani <sunnyps@chromium.org> Date: Fri Sep 07 22:26:05 2018 Enable automatic flush for canvas context Automatically growing transfer buffer removed the flush when it would run of space. This decreased canvas throughput by reducing pipelining. Automatic flushes are another way of improving throughput by submitting work to the GPU process often. This CL enables automatic flushes for the shared main thread context used for canvas which might have been disabled unintentionally. Bug: 880901 Change-Id: Ib48d9c56c18c9e2d449d7c42f74b16609ad3ea55 Reviewed-on: https://chromium-review.googlesource.com/1213665 Reviewed-by: Antoine Labour <piman@chromium.org> Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org> Cr-Commit-Position: refs/heads/master@{#589688} [modify] https://crrev.com/f3fd321621a946f69068fa5d50dc0c9c505a6bab/content/renderer/render_thread_impl.cc
,
Sep 7
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/00b22b97594d1321dea803ca8046653731f8aab6 commit 00b22b97594d1321dea803ca8046653731f8aab6 Author: Sunny Sachanandani <sunnyps@chromium.org> Date: Fri Sep 07 22:32:30 2018 [merge to 3545 canary] Enable automatic flush for canvas context Automatically growing transfer buffer removed the flush when it would run of space. This decreased canvas throughput by reducing pipelining. Automatic flushes are another way of improving throughput by submitting work to the GPU process often. This CL enables automatic flushes for the shared main thread context used for canvas which might have been disabled unintentionally. Bug: 880901 Change-Id: Ib48d9c56c18c9e2d449d7c42f74b16609ad3ea55 Reviewed-on: https://chromium-review.googlesource.com/1213665 Reviewed-by: Antoine Labour <piman@chromium.org> Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#589688}(cherry picked from commit f3fd321621a946f69068fa5d50dc0c9c505a6bab) Reviewed-on: https://chromium-review.googlesource.com/1214078 Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org> Cr-Commit-Position: refs/branch-heads/3545@{#9} Cr-Branched-From: a2bbe9dedf867fccce6d8073dc8e9c864c662bfe-refs/heads/master@{#589377} [modify] https://crrev.com/00b22b97594d1321dea803ca8046653731f8aab6/content/renderer/render_thread_impl.cc
,
Sep 8
,
Sep 8
Requested a merge to 69. There is a little bit of performance risk with this fix, but this is least risky fix in terms of stability.
,
Sep 8
This bug requires manual review: Request affecting a post-stable build Please contact the milestone owner if you have questions. Owners: amineer@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 8
Pls update bug with canary result on Monday morning.
,
Sep 8
Canary #71.0.3546.0 currently building includes change listed at #20.
,
Sep 9
Your change meets the bar and is auto-approved for M70. Please go ahead and merge the CL to branch 3538 manually. Please contact milestone owner if you have questions. Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 10
To add to the test results as updated in C#14 this showed ~24 FPS on 71.0.3545.0(build without fix) and is now showing ~28 FPS on the latest canary 71.0.3548.0(build with fix). Latest canary FPS is somewhat closer to the good build behavior as per the testing performed on Windows-10.
,
Sep 10
The NextAction date has arrived: 2018-09-10
,
Sep 10
,
Sep 10
Issue 881824 has been merged into this issue.
,
Sep 10
Change at #21 has been out on Canary since Saturday. It looks good to merge to M69.
,
Sep 10
Approving merge to M69 branch 3497 based on comment #33. Please merge ASAP. Thank you.
,
Sep 10
,
Sep 10
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2392f539d8a21692d036287fdaa99275aba00aed commit 2392f539d8a21692d036287fdaa99275aba00aed Author: Sunny Sachanandani <sunnyps@chromium.org> Date: Mon Sep 10 18:20:44 2018 [merge to M69] Enable automatic flush for canvas context Automatically growing transfer buffer removed the flush when it would run of space. This decreased canvas throughput by reducing pipelining. Automatic flushes are another way of improving throughput by submitting work to the GPU process often. This CL enables automatic flushes for the shared main thread context used for canvas which might have been disabled unintentionally. TBR=piman@chromium.org (cherry picked from commit f3fd321621a946f69068fa5d50dc0c9c505a6bab) Bug: 880901 Change-Id: Ib48d9c56c18c9e2d449d7c42f74b16609ad3ea55 Reviewed-on: https://chromium-review.googlesource.com/1213665 Reviewed-by: Antoine Labour <piman@chromium.org> Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#589688} Reviewed-on: https://chromium-review.googlesource.com/1216073 Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org> Cr-Commit-Position: refs/branch-heads/3497@{#918} Cr-Branched-From: 271eaf50594eb818c9295dc78d364aea18c82ea8-refs/heads/master@{#576753} [modify] https://crrev.com/2392f539d8a21692d036287fdaa99275aba00aed/content/renderer/render_thread_impl.cc
,
Sep 10
Note: Had to merge to manually because of ui->ws namespace changes. Verified that it compiles.
,
Sep 10
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4459bfd9798c0c8175d57e0e8b9dc3d6e945e2dc commit 4459bfd9798c0c8175d57e0e8b9dc3d6e945e2dc Author: Sunny Sachanandani <sunnyps@chromium.org> Date: Mon Sep 10 18:24:55 2018 [merge to M70] Enable automatic flush for canvas context Automatically growing transfer buffer removed the flush when it would run of space. This decreased canvas throughput by reducing pipelining. Automatic flushes are another way of improving throughput by submitting work to the GPU process often. This CL enables automatic flushes for the shared main thread context used for canvas which might have been disabled unintentionally. Bug: 880901 Change-Id: Ib48d9c56c18c9e2d449d7c42f74b16609ad3ea55 Reviewed-on: https://chromium-review.googlesource.com/1213665 Reviewed-by: Antoine Labour <piman@chromium.org> Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#589688}(cherry picked from commit f3fd321621a946f69068fa5d50dc0c9c505a6bab) Reviewed-on: https://chromium-review.googlesource.com/1217170 Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org> Cr-Commit-Position: refs/branch-heads/3538@{#235} Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811} [modify] https://crrev.com/4459bfd9798c0c8175d57e0e8b9dc3d6e945e2dc/content/renderer/render_thread_impl.cc
,
Sep 11
Tested with Version 71.0.3548.0 (Official Build) canary (64-bit) 17.25 FPS with HW Accel On 21.5 FPS with HW Accel Off Better... but you would think HW Accel would win.
,
Sep 11
#39: it depends on your canvas usage. There are many cases in which GPU Canvas rendering is faster, but the rendering you're doing may not necessarily be efficient on the GPU. Did it use to be faster in other Chrome versions?
,
Sep 11
Tested this on Win-10 using version 69.0.3497.92 and FPS count seems to have improved as compared to 69.0.3497.81(24 FPS, updated in C#14). Seeing 27-29 FPS for the repro case in C#0 on 69.0.3497.92. Hence adding the verified label.
,
Sep 11
Good news: 69.0.3497.92 is now available with the fix on Chrome Stable. You can force an update by visiting chrome://chrome. Thank you.
,
Sep 12
Adding the verified label for 70.0.3538.16 as well. Tested on Windows-10 and FPS is ~27-29.
,
Oct 1
Requesting a postmortem for this, pls see go/chrome-postmortems for more details. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by dat...@gmail.com
, Sep 5