New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Rendering glitches in High Sierra (macOS 10.13)

Reported by joel...@gmail.com, Oct 11 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36

Example URL:
https://facebook.com and https://twitter.com for sure.

Steps to reproduce the problem:
1. Use various pages in Chrome
(I have not found a reliable repro yet.)

What is the expected behavior?
Rendering is stable.

What went wrong?
Chrome rendering becomes glitchy.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? Yes macOS 10.12

Does this work in other browsers? Yes

Chrome version: 61.0.3163.100  Channel: stable
OS Version: OS X 10.13.0
Flash Version: Shockwave Flash 27.0 r0

Problem is resolved by quitting and restarting Chrome, but will repro again later. Level of corruption is distinctly worse/different than the other "flickering" issue. Attached screenshot was my Facebook feed.
 
Screen Shot 2017-10-11 at 8.27.39 AM.png
44.1 KB View Download
Showing comments 102 - 201 of 201 Older
kbr@:

Chrome Version 64.0.3258.0 (Official Build) canary (64-bit)
OS X 10.13.2 Beta (17C60c)
Launch flags: none (i.e. no --disable-gpu-rasterization)

Working absolutely fine for now.
Can confirm that http://webglsamples.org/multiple-views/multiple-views.html works in Canary (64.0.3258.0)! 

I'm getting the same fail on https://www.khronos.org/registry/webgl/sdk/tests/conformance/canvas/drawingbuffer-static-canvas-test.html: 

FAIL Line 15 should be red for at least 10 red pixels starting 20 pixels in
at (20, 15) expected: 255,0,0,255 was 0,0,0,255

In 3/4 tests I'm also seeing a slight performance increase, but that might be circumstantial. 
#103 Forgot my system details, tested on the same OS version and drivers as when testing earlier; macOS 10.13.1 and NVIDIA Web Driver 378.10.10.10.20.107.
I can confirm that the performance issues I reported with  bug #779318  are gone in the latest canary.
Anyone able to help me install Canary side-by-side with the stable version of Chrome?  I downloaded the Canary file, but really don't want to mess up my computer more than it is... Do I need to do anything special for a side-by-side install?  Or if I run the launcher will it automatically install side-by-side?
kbr@:

Chrome Version 64.0.3259.0 (Official Build) canary (64-bit)
OS X 10.13.2 Beta (17C60c)
Launch flags: none (i.e. no --disable-gpu-rasterization)

As a follow up to #102. I have just experienced two problems:

1. opening a new tab using Command+T caused the contents of the previously selected tab to be rendered in the new tab. No amount of refreshing etc fixed this
2. An in-page video (much like those that appear to the right of a Twitter feed) is currently flickering badly on a page I've loaded

Neither is reproducible on demand unfortunately. And I can't even be sure that, given #97, it isn't another application that's caused my machine to get into a "bad state."
I get this issue several times a day in Atom and Chromium.  Disabling hardware graphics acceleration makes it go away, as expected.

I'm using a 2012 MBP with dedicated NVIDIA GeForce 750M graphics.

I hope that helps narrow it down.
Re #107, just had a repeat of problem 1 mentioned in my comment with Version 64.0.3260.0 (Official Build) canary (64-bit). But again, no way of reproducing the issue. 

kbr@: are there any diagnostics I can run to tell what's gone wrong? i.e. what's caused my machine to get into a bad state? It was totally unusable when it got into this state. But then shutting down both Chrome and VMWare Fusion (which causes my machine to switch back to the integrated graphics) fixed the issue, I was able to restart both and now back up and running just fine.

Otherwise however, things seem _much_ better per my other comments.
Re #109 (sorry for the noise, want to make sure however that my reports are current and accurate). 

OS X 10.13.2 Beta (17C60c)
Chrome Version 64.0.3260.0 (Official Build) canary (64-bit)
GPU details attached

Running with "GPU Rasterization" as "Default"
=============================================
Now seeing multiple glitches when running Chrome alongside VMWare Fusion (not sure which app causes the issues). Ultimately leads to machine becoming totally unusable, needing me to shutdown both apps (which causes machine to revert back to integrated graphics card) then restarting both I'm back in a good state until things go bad again.

Running with "GPU Rasterization" as "Disabled"
==============================================
No glitches, and machine runs fine generally (i.e. VMWare Fusion runs just fine). But makes Chrome almost impossible to use because it slows down to a crawl with ~5 tabs open.

----------

So it seems Chrome, with "GPU Rasterization" set to "Default" (which I'm assuming is enabled) is sending my machine into a bad state (as opposed to any other program), which then causes my machine to grind to a halt. 

But for me, disabling "GPU Rasterization" seemingly isn't really an option either.
gpu_20171106.html
62.8 KB View Download
Hi,
I'm thinking of downgrading back to Sierra (complete reinstall) because I suffer of too many problems and slugish on High Sierra.
Will i get my smooth MacBook Pro back to normal ? or by upgrading to High Sierra it also upgraded some firmware without going back.

Thanks
Re #111

I don't think this is the place to discuss this. You will probably get better answers on forums/websites that focus on Mac OS X support (not this one) but I'm going to respond to you anyway. 

A 2014 MacBook Pro with your specs should not feel sluggish on High Sierra. I'm working on one everyday (with Parallels.) There's probably something wrong with your setup. Does your parallels VM hog all the resources? Do you have any (misbehaving) background processes or drivers hogging your resources?
You could just do a clean reinstall of High Sierra.

BTW, I do also have the rendering issue. I figured I just wait patiently for a fix to arrive.
Thanks for all the testing! One last thing that might be worth trying (on the latest Canary) is running with "--disable-native-gpu-memory-buffers --disable-zero-copy". If someone is still experiencing issues on Canary, can you try these flags out and see if they resolve things? Thanks!
Note regarding the merge to M63 - I think we need another update to this CL and potentially another week of testing in Canary. I'll decide on the change I'd like to make by today or early tomorrow, and let's target next week's M63 build if things look good?
Re #114: OK if things look good and Cl is safe to merge. Please note merge has to happen by 4:00 PM PT Monday (11/13) so we can pick it up for next week beta release. Thank you.
Re #113 - will try those flags tomorrow.

Just to confirm:

--disable-native-gpu-memory-buffers doesn't appear to have an equivalent in about:flags, correct?

--disable-zero-copy appears to correspond to about:flags "Zero-copy rasterizer"

Will run from the command line in any case.


Re #113; will test more fully tomorrow, but with these flags immediate feedback is that YouTube videos have audio but a black screen where the video itself should be display.
Hey paul@, good point - seems like one of these flags has a bad interaction with video on its own. Followed up with a coworker, and it sounds like we need one more flag. Unfortunately this does require running from the command line: --disable-gpu-memory-buffer-video-frames

So to summarize, the most valuable thing to test would be latest Canary with:

--disable-native-gpu-memory-buffers --disable-zero-copy --disable-gpu-memory-buffer-video-frames

If this works, I'll have to re-work the patch from #91.

Also, if anyone else can try out this combination of three flags on the latest Canary, it would be really appreciated.



Please don't disable GPU acceleration again for OpenGL surfaces ....
So basically once this goes live... everyone affected won't be able to use chrome because ALL websites will start to crawl... just disabling Gpu Rasterization you can't even run google sheets... 

This is a complete disaster... does anyone have any contacts at apple to get some eyes on this? 
Re #118: here is a gist that contains an experience report with the settings you wanted tested: 

https://gist.github.com/myitcv/73473dc0e1d1e484f988eb206b4420b5

Includes a summary, system details, issues list, errors list and gpu details for completeness.

Headline: 90-95% of the time absolutely fine. Good speed, responsiveness etc, with some link between the use of WhatsApp web and the issues I experienced the remaining 5-10% of the time.

Please let me know if you need any more details.
Re #121 - Thanks so much for the additional info Paul. I'll do some testing on Whatsapp's mobile site today and see if I can find a reliable way to trigger this issue.

Re #120 - We've contacted Apple and they are aware of the issue. Unfortunately, they're having trouble reproducing the issue on their end (and I can only rarely reproduce the issue). I'm hoping the Whatsapp scenario paul@ mentions in #121 proves to be a reliable repro, but if anyone else has a set of sites or actions which reliably cause visual corruption on the latest Canary, please let me know. Thanks!
A quick follow-up re #118 - you never experienced these system-wide slow-down issues when running with --disable-gpu-rasterization on latest Canary, right? Or could that have been the "slowing down to a crawl" you experienced? I actually don't think GPU rasterization should have that dramatic of an impact on most sites, so I'm surprised by your findings in #110 - I wonder if it could have been the same issue we see here?
Re #123:

> you never experienced these system-wide slow-down issues when running with --disable-gpu-rasterization on latest Canary, right?

Just retested with just "--disable-gpu-rasterization". Chrome is unusable for me in this configuration; it's sluggish between tabs, within tabs, switch to/from Chrome and other apps. 

So whilst the other apps might themselves be ok, Chrome basically kills my machine with "--disable-gpu-rasterization" alone. 

Restarting Chrome and reverting to the setup as reported in #121, all is good again.
ericrk@chromium.org, I feel a lot of time is lost waiting for replies here and attempting to recreate the issue. Can't you just take control of my system remotely? Happy to get on a call too. Having no issues recreating, even seeing some really weird stuff in Canary, like http://webglsamples.org/multiple-views/multiple-views.html freezing and loading a red page on refresh. 
Re #121: I had another instance of the shadow tabs thing in Version 64.0.3262.0 after stopping screen sharing in a Google Hangout session in my second Chrome profile (then switching windows back to my main Chrome profile). Whether the following error messages from my console are relevant or not I'm not sure:

[45674:49411:1109/171407.979023:ERROR:service_manager.cc(158)] Connection InterfaceProviderSpec prevented service: content_renderer from binding interface: blink::mojom::ReportingServiceProxy exposed by: content_browser
[45674:49411:1109/171407.979211:ERROR:service_manager.cc(158)] Connection InterfaceProviderSpec prevented service: content_renderer from binding interface: blink::mojom::ReportingServiceProxy exposed by: content_browser
[45674:49411:1109/171414.480992:ERROR:service_manager.cc(158)] Connection InterfaceProviderSpec prevented service: content_browser from binding interface: chrome::mojom::ResourceUsageReporter exposed by: nacl_loader
[96313:50743:1109/171414.505230:ERROR:peerconnection.cc(2766)] channel label not found
[96313:3851:1109/171439.597406:ERROR:call.cc(1351)] receive_rtp_config_ lookup failed for ssrc 2819971124
[45674:49411:1109/175630.843051:ERROR:service_manager.cc(158)] Connection InterfaceProviderSpec prevented service: content_renderer from binding interface: blink::mojom::ReportingServiceProxy exposed by: content_browser
Project Member

Comment 127 by bugdroid1@chromium.org, Nov 9 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/400103206e96e1538627ba3af95740c2a4f0a359

commit 400103206e96e1538627ba3af95740c2a4f0a359
Author: Eric Karl <ericrk@chromium.org>
Date: Thu Nov 09 19:23:47 2017

Revert "Allow blacklisting of use of GpuMemoryBuffers as render targets."

This reverts commit a28eb737c4c9424d7656ada19b688af854777968.

Further debugging indicates that this fix isn't addressing the original issues, and that the
WebGL issues likely have a different root cause.

TBR=kbr,piman,junov

Bug:  773705 ,  778770 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I2eba58f1c8e87773fa6ed51e0273adbe24e33174
Reviewed-on: https://chromium-review.googlesource.com/758964
Commit-Queue: Eric Karl <ericrk@chromium.org>
Reviewed-by: Justin Novosad <junov@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Eric Karl <ericrk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#515236}
[modify] https://crrev.com/400103206e96e1538627ba3af95740c2a4f0a359/cc/DEPS
[modify] https://crrev.com/400103206e96e1538627ba3af95740c2a4f0a359/content/browser/compositor/gpu_process_transport_factory.cc
[modify] https://crrev.com/400103206e96e1538627ba3af95740c2a4f0a359/content/renderer/pepper/ppb_graphics_3d_impl.cc
[modify] https://crrev.com/400103206e96e1538627ba3af95740c2a4f0a359/content/renderer/pepper/ppb_graphics_3d_impl.h
[modify] https://crrev.com/400103206e96e1538627ba3af95740c2a4f0a359/gpu/command_buffer/service/feature_info.cc
[modify] https://crrev.com/400103206e96e1538627ba3af95740c2a4f0a359/gpu/config/gpu_driver_bug_list.json
[modify] https://crrev.com/400103206e96e1538627ba3af95740c2a4f0a359/gpu/config/gpu_driver_bug_workaround_type.h
[modify] https://crrev.com/400103206e96e1538627ba3af95740c2a4f0a359/gpu/config/software_rendering_list.json
[modify] https://crrev.com/400103206e96e1538627ba3af95740c2a4f0a359/third_party/WebKit/Source/platform/graphics/CanvasResourceProvider.cpp
[modify] https://crrev.com/400103206e96e1538627ba3af95740c2a4f0a359/third_party/WebKit/Source/platform/graphics/DEPS
[modify] https://crrev.com/400103206e96e1538627ba3af95740c2a4f0a359/third_party/WebKit/Source/platform/graphics/gpu/DEPS
[modify] https://crrev.com/400103206e96e1538627ba3af95740c2a4f0a359/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.cpp

Project Member

Comment 128 by bugdroid1@chromium.org, Nov 9 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6fa5813dbf5b2ee7e449f983e87e5aa73d196cd4

commit 6fa5813dbf5b2ee7e449f983e87e5aa73d196cd4
Author: Eric Karl <ericrk@chromium.org>
Date: Thu Nov 09 22:16:16 2017

Re-enable accelerated 2D Canvas on NVidia High Sierra

Re-enabling accelerated 2D Canvas, as without acceleration performance
was bad enough that Canvas2D became unusable in common cases. If
deciding between occasional visual corruption and unusable performance,
visual corruption seems to be the lesser issue.

Note that this keeps GPU Raster blacklisted. This is unfortunate, but
was only enabled 1yr ago, so should have less sites with a hard
dependency.

Bug:  773705 
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I1f33a6769fb6691b839f768326c153dfdedf13ff
Reviewed-on: https://chromium-review.googlesource.com/759236
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Eric Karl <ericrk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#515315}
[modify] https://crrev.com/6fa5813dbf5b2ee7e449f983e87e5aa73d196cd4/gpu/config/software_rendering_list.json

Used the flags "--disable-native-gpu-memory-buffers --disable-zero-copy --disable-gpu-memory-buffer-video-frames " as mentioned in comment#18 and launched chrome version 64.0.3264.0, on Mac 10.13 Beta (17A360a) and then followed the steps as mentioned in comment#33 using a Discrete GPU (GPU: NVIDIA GeForce GT 650M, Intel HD Graphics 4000). No rendering glitches was observed.

Are there any other steps to be performed to validate the issue.

Thanks.!

With the change in #128, we've moved to a mode where GPU raster is disabled but accelerated canvas is enabled. This will improve performance over M62. This may introduce rendering glitches in some Canvas cases. This trade off seemed preferable to to the performance hits we were seeing.

We're going to let this change soak on Canary over the weekend. If things seem good, we'd like to merge https://chromium-review.googlesource.com/c/chromium/src/+/759236/ to M63 on Monday.

Re #129 - I think we're backing off of that line of investigation, as blacklisting GPU memory buffers didn't seem to fix issues for all users.

Thanks!
NextAction: 2017-11-13
The NextAction date has arrived: 2017-11-13
Re follow ups to #121 and #124, please can I ask what the latest is?

I'm still running with "--disable-native-gpu-memory-buffers --disable-zero-copy --disable-gpu-memory-buffer-video-frames" - is this correct? Or has Canary effectively been updated with these defaults?
Hi paul@, thanks for the continued testing. At this point I'd just run as normal. In the latest build, we've re-enabled Accelerated 2D Canvas, but disabled GPU raster. We couldn't find a better solution to the visual corruption.
Re #132; Ericrk@ - if I run Canary as normal things get _very_ sluggish when the discrete graphics card is in use. For example, cycling between tabs using Cmd+Alt+Left/Right there is a very noticeable lag. 

Contrast when I run with "--disable-native-gpu-memory-buffers --disable-zero-copy --disable-gpu-memory-buffer-video-frames", everything is much snappier. 

So for me, running Canary with no flags is not an option right now. Seemingly whatever defaults are set is not the same as the "--disable-native-gpu-memory-buffers --disable-zero-copy --disable-gpu-memory-buffer-video-frames" flag combination.
Interesting... That's very surprising, as I wouldn't expect those flags to have much of an impact. BTW, are you running the latest 10.13.2 (beta 2)?
Labels: Merge-Request-63
Re requesting merge to m63. Per comment 130, this should be an improvement over m62 stable (discussion above is related to whether this is an improvement over previous canary). This change has been in canary for a few days and we haven't had reports of any unexpected canvas issues.
Project Member

Comment 138 by sheriffbot@chromium.org, Nov 14 2017

Labels: -Merge-Request-63
This bug requires manual review: DEPS changes referenced in bugdroid comments.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Note that the merge request above is only for the CL in #128. Thanks!
Re #136 - I'm running 10.13.2 beta 3 and it's still an issue with Chrome Version 64.0.3265.0
To summarize the merge justificaiton:

In M62, GPU Raster and Accelerated Canvas were blacklisted. Blacklisting accelerated canvas results in severe performance issues on common sites. We were unable to find a better workaround as of now, so we decided to un-blacklist just Accelerated Canvas. This *may* result in some visual glitches, but this feels very preferable to common canvas sites not working at all.

The change is a very small / safe change to our blacklisting rules that moves us from our M62 canvas behavior to our M61 canvas behavior. Both paths are in use on different machines and well tested. Additionally, this has been in Canary for a number of days and no unexpected canvas related issues have been reported.
Labels: -Merge-Review-63 Merge-Approved-63
Thank you ericrk@.

Approving merge for Cl listed at #128 to M63 branch 3239 based on comments #139 and #141 and per offline chat with ericrk@.
Thanks paul@ - just to confirm, the performance you're seeing on the latest Canary is similar to the performance on Stable (no flags for both)?

I don't know why disabling IOSurfaces/GPU Memory Buffers speeds things up so much for you. I think we should open a new bug for this (potentially blocking this one) and have ccameron@ investigate. I'll do this now.
Blockedon: 784938
Project Member

Comment 145 by bugdroid1@chromium.org, Nov 14 2017

Labels: -merge-approved-63
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/915698ffed14239cd04a83a23a3e1d4c856a7069

commit 915698ffed14239cd04a83a23a3e1d4c856a7069
Author: Eric Karl <ericrk@chromium.org>
Date: Tue Nov 14 18:29:08 2017

Re-enable accelerated 2D Canvas on NVidia High Sierra

Re-enabling accelerated 2D Canvas, as without acceleration performance
was bad enough that Canvas2D became unusable in common cases. If
deciding between occasional visual corruption and unusable performance,
visual corruption seems to be the lesser issue.

Note that this keeps GPU Raster blacklisted. This is unfortunate, but
was only enabled 1yr ago, so should have less sites with a hard
dependency.

TBR=ericrk@chromium.org

(cherry picked from commit 6fa5813dbf5b2ee7e449f983e87e5aa73d196cd4)

Bug:  773705 
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I1f33a6769fb6691b839f768326c153dfdedf13ff
Reviewed-on: https://chromium-review.googlesource.com/759236
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Eric Karl <ericrk@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#515315}
Reviewed-on: https://chromium-review.googlesource.com/769232
Reviewed-by: Eric Karl <ericrk@chromium.org>
Cr-Commit-Position: refs/branch-heads/3239@{#483}
Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578}
[modify] https://crrev.com/915698ffed14239cd04a83a23a3e1d4c856a7069/gpu/config/software_rendering_list.json

Labels: TE-Verified-63.0.3239.52
Tested this issue on Mac 10.13 Beta (17A360a) with chrome version #63.0.3239.52 fix is working as intended. Followed the steps as mentioned in comment#33 using a Discrete GPU (GPU: NVIDIA GeForce GT 650M, Intel HD Graphics 4000). No rendering glitches was observed (Screencast Attached).

Hence adding Verified labels.

Thanks!!
773705.webm
16.6 MB Download

Comment 148 by kbr@chromium.org, Nov 16 2017

Blocking: 781598

Comment 149 by kbr@chromium.org, Nov 21 2017

Blocking: -775202

Comment 150 by kbr@chromium.org, Nov 21 2017

Blockedon: 775202
For the record I've downgraded to Mac OS X Sierra because this became too painful to manage on a daily basis. 
Apple indicated that this *might* be fixed on the latest macOS 10.13.2 beta. There was also a recent NVIDIA driver update, but that probably hasn't landed on the macOS beta yet, and didn't have any effect on the issue for me in any case. Has anyone tested the latest macOS beta? 
I've tried http://webglsamples.org/multiple-views/multiple-views.html on three computers:

- Linux with Chromium: appears to work as expected
- macOS 10.13.2 with Chrome Version 61.0.3163.100 (Official Build) (64-bit): top right view looks good, but other views alternate frames flashing what appears to be solid red and the correct scene (but perhaps tinted red?)
- macOS 10.13.2 with Safari: appears to render correctly but all views tinted red.

It appears that my version of Chrome might be out of date so I'll try reinstalling and see if it helps - auto update is not working.
Screen Shot 2017-12-07 at 10.44.50 AM.png
470 KB View Download
I updated to latest Chrome: Version 63.0.3239.84 (Official Build) (64-bit)

It still has issues.
Flashing.mov
7.6 MB Download

Comment 155 by kbr@chromium.org, Dec 6 2017

#153: the fix for the multiple-views.html test case was in  Issue 778770  and will ship in Chrome 64. That fix affected basically only that test and didn't warrant merging back to Chrome 63.

Feel free to file a bug on bugs.webkit.org about issues with that test in Safari.

Cc: julien.isorce@chromium.org

Comment 157 by kbr@chromium.org, Dec 21 2017

Blocking: 796634
Should this still be marked RBS? It sounds like the issue is not in Chrome, and we don't really have good ways to workaround?
Labels: -Hotlist-Merge-Review -Pri-1 -ReleaseBlock-Stable Pri-2
Owner: ccameron@chromium.org
Status: ExternalDependency (was: Started)
I don't think this should be RBS any more... I think we've worked around this as possible and are just waiting on OS level fixes.

Over to ccameron@ for future triage, but I don't think there's much to do other than wait for the Apple fixes. Marking as external dependency.
Labels: Needs-Feedback
Can we verify that this is still an issue on Canary?
I have huge performace drop in Sierra as well after updating chrome to 62 and 63. All my html 5 games lag and use a lot of CPU. gpu.html attached. Are you sure it's connected with WebGL driectly?

Comment 162 by kbr@chromium.org, Jan 22 2018

about:gpu content wasn't attached in the last comment.

ahh, sorry, attached here
gpu.htm
58.3 KB View Download

Comment 164 by kbr@chromium.org, Jan 23 2018

gprzybylowicz@: I don't see anything in your about:gpu that looks broken. If you see a reliable slowdown on some web page and can confirm it with the Chromium continuous snapshots here:
https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Mac/

then please file a new bug and include the repro case. Thanks.

Guys, how can I force enable the gpu_rasterization option in Chrome under iMac 2013 with Nvidia GPU? I'm having a huge performance drop while it's being disabled and thinking of moving from using Chrome any longer due to this. Any real workaround here?
There have been several High Sierra point releases since this issue was first reported, but as far as I know nothing addressing the problem from Nvidia or Apple's end. While the UI rendering issues have been resolved by a Chromium patch, Chromium based apps now suffer from degraded performance on affected graphics cards due to the disabling of GPU rasterization.

Specifically, I'm on a Mid-2012 MacBook Pro with an Nvidia GeForce 650M on High Sierra 10.13.3. I'm seeing severely degraded UI performance in Chrome Stable 64 and Canary 66 while scrolling, switching tabs, etc. I installed a clean copy of Sierra 10.12.6 and Chrome performance was snappy, as it always has been. I then installed a clean copy of High Sierra 10.13.3 and Chrome performance was once again degraded.

I've opened a new bug report with Apple, see https://goo.gl/s78TMx

Here are the results of chrome://gpu from Chrome 64, https://goo.gl/g4CL2P

Note:
Rasterization: Software only, hardware acceleration unavailable
Macs with NVidia GPUs experience rendering issues on High Sierra: 773705
Disabled Features: gpu_rasterization

Not sure where to go from here.
I can confirm the same behaviour, but with AMD GPU. My setup is:

MacBook Pro Retina 15" Mid2015
macOS 10.13.3 (17D47)
2,8 GHz Intel Core i7
16 GB 1600 MHz DDR3
AMD Radeon R9 M370X 2 GB
Intel Iris Pro 1536 MB

Google Chrome 64.0.3282.140

I experienced this issue only when external monitors are attached, so I guess the Intel Iris works fine when rendering just one monitor. After connecting other monitors (graphics card switch), the degraded performance is instantly noticeable. It seems only to be on Chrome though, as rendering the same websites in Firefox or Safari works just fine. Also, I cannot confirm the issue in the electron apps like Slack, which is still working as normal.

The issues started after recent upgrades, maybe either macOS 10.13.2 => 10.13.3 or Chrome 63 => 64. I did both updates around the same time, so I don't really know which one caused it.
I was able to solve this on my machine by resetting the NVRAM (see https://support.apple.com/de-de/HT204063). So after alt+cmd+p+r during a reboot (right after first boot sound), the problems are completely gone now for me. Maybe this also works in other circumstances.
This began happening on my MBP Retina 15-inch, Mid-2015, running macOS Sierra v10.12.6 in electron apps. I was only able to get the running using the disable-gpu flag.

Just wanted to confirm that the above suggestion of resetting the NVRAM seems to have cleared up the issue for me. 
For the performance degradation issue, I want to add that the NVRAM reset solution probably only work for AMD based systems. It did nothing to my late 2013 MBP with Nvidia graphics card.

On the other hand, the newest Chrome 66 does seem to have resolved all performance issue that I was having, at least with the separately installed Nvidia drivers -- not sure if that matters because the driver didn't help on earlier Chrome versions.

Comment 172 Deleted

Apple has responded to my bug report regarding this issue (see https://goo.gl/rRdLiv) with the following: 

"The original report on this issue, Bug ID 36754190, is closed as resolved in macOS 10.13.4 betas. If you still see the issue in that or a newer release, please file a new bug report."

If this is indeed fixed in 10.13.4 hopefully it will be possible to roll back the patch that disabled GPU rasterization and other hardware optimizations on affected Nvidia hardware. 

Fingers crossed!
Re #173: thank you _very_ much for a) following up so patiently with Apple and b) posting the details of the bug report. I had a hugely frustrating time trying to make any progress... so glad to hear that there's a potential fix in the works.

Have you, by any chance, tried beta 4 to confirm it's fixed?

I have a very specific repro step (the results posted in https://bugs.chromium.org/p/chromium/issues/detail?id=773705#c64 with a broken setup) for anyone who was affected and is willing/able to test. Please let me know.
Re #174: No problem!

Unfortunately I don't have a spare Mac to test the 10.13.4 beta on. I'll of course give the final release a try when its released.

Can anyone confirm which chrome://flags need to be manually enabled to re-enable full GPU acceleration on affected hardware?
macOS 10.13.4 is released and works fine for me. I guess that means you guys can fully enable all optimizations again for the Mac ?
I've just upgraded to macOS 10.13.4 and still have performance issues. Chrome and any other Chromium based application such as Slack, Spotify, Postman, etc. are still unusable. I can only use Chromium based apps with hardware acceleration turned off. I wonder how long Nvidia and Apple will take to figure this out. 
Ok, seems like the 10.13.4 update has fixed that issue but Chrome is still disabling gpu_rasterization. Waiting for the next Chrome update to enable it?
I'll update Chrome to allow 10.13.4.
Thanks, that would be nice.
Just to ask the perhaps obvious question, but has anyone from Apple confirmed this is fixed in 10.13.4?
Yes, they confirmed. See above, it was stated already. Anyway, Chrome works a bit faster after the 10.13.4 update. So, my guess is enabling hardware acceleration should work.
Re 182 - apologies, yes I forgot about 173 (which is bizarre because I responded to it in 174)!
Project Member

Comment 184 by bugdroid1@chromium.org, Apr 13

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/40ae08bc002c3cda5737b7c7c0b6567714c22ff4

commit 40ae08bc002c3cda5737b7c7c0b6567714c22ff4
Author: Christopher Cameron <ccameron@chromium.org>
Date: Fri Apr 13 08:15:19 2018

Re-enable GPU raster and HW canvas on 10.13.4 and above

The stability issues in 10.13's earlier releases appear to have been
fixed in 10.13.4.

Bug:  773705 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: Ib483847c6b8b8779448b6d47d5ab3cd6a72d2c34
Reviewed-on: https://chromium-review.googlesource.com/1011252
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550544}
[modify] https://crrev.com/40ae08bc002c3cda5737b7c7c0b6567714c22ff4/gpu/config/software_rendering_list.json

Project Member

Comment 185 by bugdroid1@chromium.org, Apr 17

Labels: merge-merged-testbranch
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/40ae08bc002c3cda5737b7c7c0b6567714c22ff4

commit 40ae08bc002c3cda5737b7c7c0b6567714c22ff4
Author: Christopher Cameron <ccameron@chromium.org>
Date: Fri Apr 13 08:15:19 2018

Re-enable GPU raster and HW canvas on 10.13.4 and above

The stability issues in 10.13's earlier releases appear to have been
fixed in 10.13.4.

Bug:  773705 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: Ib483847c6b8b8779448b6d47d5ab3cd6a72d2c34
Reviewed-on: https://chromium-review.googlesource.com/1011252
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550544}
[modify] https://crrev.com/40ae08bc002c3cda5737b7c7c0b6567714c22ff4/gpu/config/software_rendering_list.json

Blocking: 823335
Labels: Merge-Request-67
I'm going to want to merge #185 to M67 cause it missed the branch point by a little bit.
Hey guys, I've just updated to Version 66.0.3359.117 (Official Build) (64-bit)
and still have the gpu_rasterization disabled. Is there anything I should do on my end?
Project Member

Comment 189 by sheriffbot@chromium.org, Apr 18

Labels: -Merge-Request-67 Merge-Review-67 Hotlist-Merge-Review
This bug requires manual review: DEPS changes referenced in bugdroid comments.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
How is change listed at #184 looking in canary? Will it be safe to merge to M67?
I think that this is okay to merge to M67 now. Unfortunately it's something that won't have an immediately visible impact on any channel, but I think we should get it merged earlier so that if there are problems, we can remove it (it's trivial to remove).
Labels: -Merge-Review-67 Merge-Approved-67
Approving merge for CL listed at #184 to M67 branch 3396 based on comment #191. Please merge ASAP. Thank you.
Project Member

Comment 193 by bugdroid1@chromium.org, Apr 19

Labels: -merge-approved-67 merge-merged-3396
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e9b6fe054991cc76c4a67c4052949be63d1b1c73

commit e9b6fe054991cc76c4a67c4052949be63d1b1c73
Author: Christopher Cameron <ccameron@chromium.org>
Date: Thu Apr 19 20:35:20 2018

Re-enable GPU raster and HW canvas on 10.13.4 and above

The stability issues in 10.13's earlier releases appear to have been
fixed in 10.13.4.

TBR=ccameron@chromium.org

(cherry picked from commit 40ae08bc002c3cda5737b7c7c0b6567714c22ff4)

Bug:  773705 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: Ib483847c6b8b8779448b6d47d5ab3cd6a72d2c34
Reviewed-on: https://chromium-review.googlesource.com/1011252
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: ccameron <ccameron@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#550544}
Reviewed-on: https://chromium-review.googlesource.com/1020224
Reviewed-by: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/branch-heads/3396@{#147}
Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428}
[modify] https://crrev.com/e9b6fe054991cc76c4a67c4052949be63d1b1c73/gpu/config/software_rendering_list.json

Status: Fixed (was: ExternalDependency)
Marking fixed now that this is re-enabled for 10.13.4.
Cc: bsalomon@chromium.org vmiura@google.com ligim...@chromium.org a...@chromium.org vamshi.kommuri@chromium.org susan.boorgula@chromium.org
 Issue 823335  has been merged into this issue.
Tested this on Mac OS 10.13.3 on chrome version: 67.0.3396.18 to check if the recent CL in C#193 has not broken anything.

Tried verifying as per the steps mentioned in comment# 33. As per the provided screencast tried to download the menu bar application from URL: https://gfx.io/, while installing the application it is showing the warning message like: "You are using a system that gfxCardStatus does not support. Please ensure that you are using a MacBook Pro with dual GPUs". Since dual GPU is not available hence unable to check the steps from C#33.

@Christopher Cameron: Could you please confirm if any alternate steps to help us in verifying the latest CL.

Thanks
Re #196, I don't think we can explicitly re-verify this -- we just have to keep our eyes peeled for new bug reports on 10.13.14 about this issue re-appearing.
If anyone who a) has a MacbookPro that was affected by this in 10.13.3 and earlier and b) has since upgraded to 10.13.4, were willing, there is a specific test that can be performed that does not rely on Chrome mentioned in https://bugs.chromium.org/p/chromium/issues/detail?id=773705#c64. I personally would be very grateful if someone were able to test that on my behalf (I'm still running 10.12.6 after downgrading). 

Re #197 - the test I've just linked to was a reliable indicator of a problem for me outside of Chrome in case that's useful.
Re #198: I would suggest you wait a bit more till Chrome pushes the 67 update so we could test. Currently I'm still having this: https://prnt.sc/jd1zoe with 10.13.4 and Chrome v.66
Please could I ask, any further updates from folks with NVidia discrete graphics setups who have taken the plunge and upgraded to >= 10.13.4?

How are things working out?
For the record, in response to #200, I just tried upgrading to 10.13.5 - same issue with Chrome, my non-Chrome reproduction, even with the NVidia provided drivers. So restored from Time Machine backup to 10.12.6
Showing comments 102 - 201 of 201 Older

Sign in to add a comment