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 Back to list
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
Components: -Blink Blink>Compositing Blink>Paint
Labels: -Pri-2 Pri-1
Possibly related to  issue 773354 
Labels: Needs-Triage-M61
Seeing this on Electron based apps, too: https://github.com/electron/electron/issues/10736

I'm on a Mid-2012 Retina Macbook Pro. Disabling "Automatic graphics switching" in "Energy Saver" in System Preferences may be acting as a workaround, but I don't know for sure yet. (RIP my battery.)
Components: -Blink>Compositing -Blink>Paint Internals>GPU>VendorSpecific
Labels: -Needs-Triage-M61
Yep, this seems to be some issue with the MacOS 10.13 graphics system and certain MacBooks. We've had a few reports of issues and it probably comes down to a narrow range of hardware.

I've asked for hardware information over on  issue 773354 .
I've had this problem in Chrome (61) and in Electron apps (1.7.x) on macOS 10.13 on a MacBookPro 11,3. Attached is my about://gpu page in case that helps.
gpu.html
51.4 KB View Download
In case it helps, here are other issue threads for apps being affected by this same Chromium issue:
https://github.com/Microsoft/vscode/issues/35527
https://github.com/electron/electron/issues/10736
https://github.com/wavebox/waveboxapp/issues/395
Cc: pbomm...@chromium.org vmi...@chromium.org ccameron@chromium.org
Thanks for the information. If anyone experiencing this issue can attach the contents of their "about:gpu" page (save-as webpage:complete), preferably from a session that experienced the bug, it would help us narrow down the issue.

pbommana@, do you have any high-sierra macbooks - ideally 2013 models - on which we can try to get a repro?
Cc: ericrk@chromium.org
Status: Available
I can reproduce this on my early-2013 MBP after upgrading to sierra. It seems like arbitrary tiles are being dropped, but interestingly there are no errors in about:gpu after the issue occurs. Note that it is hard to repro, took me 10 or 15 minutes.
This also happens for me quite a lot, also in Electron based apps.

Here is a GPU page dump right after it happened to me.
gpu.htm
57.6 KB View Download
Note that all instances seen so far in this thread appear to have a discrete NVidia GPU active. Might be an NVidia-driver specific issue.
zoltan@, are there any specific sites that trigger the issue more frequently for you. We have the same hardware, so I expect I'll be able to hit this reliably, but am having a bit of trouble.

Additionally, are you using your mac connected to an external monitor?

Thanks for the help!
I can confirm, It happens to me with external monitor.
Cc: kbr@chromium.org
Owner: ericrk@chromium.org
Status: Started
kbr@, vmiura@ - do we have an NVidia contacts who might be able to help here?

To summarize what we've found so far:

It appears that when using a discrete NVidia GPU, we occasionally get into a bad state where GL commands start failing. Interestingly, these commands fail silently, with no errors logged to about:gpu. These failures look like some sort of memory corruption in the driver. Each time failures occur, the symptoms are slightly different. Typically tiles will disappear and video playback will fail, but in one case I got graphical corruption across the whole OS (menu bar, dock, other apps).

Interestingly, when visual corruption is present, switching to the integrated (Intel) GPU fixes the issue, and switching back to the discrete NVidia GPU causes the issue to immediately resume. This further indicates a driver issue to me.

Unfortunately, this issue is very hard for me to repro (takes ~1hr to get it to occur), so I've been unable to do any meaningful bisection or experimentation to determine what feature might be responsible.

I plan to file a bug with Apple today.
 Issue 773745  has been merged into this issue.
Cc: krajshree@chromium.org junov@chromium.org
 Issue 772735  has been merged into this issue.
Comment 17 Deleted
Comment 18 Deleted
Added my GPU information as requested in https://bugs.chromium.org/p/chromium/issues/detail?id=772735#c8
Cc: oetu...@nvidia.com
Olli Etuaho at NVIDIA (now CC'd) is our primary contact, but someone else works on the Mac driver team. I'll connect you via email.

Blocking: 775202
 Issue 775202  might have a fairly reproducible test for at least one kind of intermittent rendering bug on macOS 10.13.

Also has been happening for me, ever since I upgraded to High Sierra.  I have a mid-2012 Macbook Pro (discrete NVIDIA GeForce GT 650M 1 GB).


I attached my gpu.htm to this post - hope it helps.  Trying to get a good video of the issue (it's especially funky when scrolling), but it's difficult.

gpu.htm
66.0 KB View Download
Attached a screen recording of the video based flickering/corruption I sometimes see in Twitter's RHS panel
chrome_video_flickering.mov
1.6 MB Download
Incidentally, Google Chrome 63.0.3239.9 dev appears (although I'm still trying to track down whether it was this update and not something else) to have rendered my machine almost completely unusable. Again, it appears to be graphics-related, hence my adding the comment to this issue.

Revert to using Beta for now.
ericrk@chromium.org

Yes, facebook and apps that use my webcam seem to be more affected. I have videos of the glitch, but i wouldn't post them here. Ping me in private if you'd like to see them.
If you're experiencing this issue, can you please open "about:flags" and find the entry labeled "Gpu Rasterization" and try setting this to "disabled". This may address the issue, but it would be great to confirm that this fixes it for everyone.
Labels: ReleaseBlock-Stable M-62
Cc: manoranj...@chromium.org
Mano, can you please try a repro. 

As per Eric, bug should repro on any ~2013 or late 2012 mac with NVidia hardware.Seems like we're considering a merge to M62 stable, but want to understand the options for mitigating (do we need to disable GPU entirely, or are certain GPU features such as Canvas and GPU raster enough)
ericrk@chromium.org - will try disabling "Gpu Rasterization"

I also use Slack's desktop Electron app - not sure how to disable Gpu Rasterization there?
I'm also experiencing this same issue in an Electron app (v1.6.11) that worked perfectly before upgrading to Mac OS High Sierra (10.13).

I wanted to note that I do not have an NVIDIA card. I instead have the following machine specs:

MacBook Pro (Retina, 13-inch, Early 2015)
3.1 GHz Intel Core i7
16 GB 1867 MHz DDR3
Intel Iris Graphics 6100 1536 MB

I've attached my gpu.html in case its helpful since my case is for an Intel video card.
gpu.html
52.6 KB View Download
sachin.rekhi@ - so far the other reports have been from an NVidia card, so this is interesting. Can you describe the exact visual issues you're seeing?
I think, i am able to reproduce this issue finally with 'Discrete GPU' and works fine w/ 'Integrated GPU' for reported chrome version#61.0.3163.100 on OS X 10.13.1 Beta (17B35a), MacBook Pro (Retina, Mid 2012) [NVIDIA GeForce GT 650M 1 GB & Intel HD Graphics 4000 1536 MB]. As of now, i do not see this issue on Canary#64.0.3243.0.

Thank you!
Oct 19 2017 4-37 PM.webm
3.1 MB View Download
Comment 34 Deleted
Tried with "--disable-gpu-rasterization" for same Chrome version and so far (~40 mins) i do not see the same behavior as #33. So we might use this as work around as ericrk@ suggested.
ericrk@ - after looking into further, I figured out I had a different Electron issue specific to High Sierra unrelated to this. Apologies for the confusion!
I'm hitting these same issues.  Animated GIF causing corrupt previews, but also all WebGL tabs going black and unrecoverable after returning to them after 15 minutes of non-use.  I'm using the Nvidia 750m in a MB Pro 2013 with OSX 10.13.  This never happened in OSX 10.12.4 that I was using previous to the update.

I've also had OpenGL rendering (NSOpenGLView) draw outside the window, and then triangles and pixels flash all over the screen.  This also breaks the WebGL tab views.

In the past, I've see flashing like this from failing to update renderbuffer id's after presenting the renderbuffer.  When OSX does double buffering, it can toggle between two different ids, and so you need to save/restore the correct id if you switch to a texture (not just assume id = 0).


Clicking on an image in Twitter (in Chrome), which causes the image to "full screen" within the tab, just caused my entire machine to crash after a period of about 5 secs flickering. 

Got the message "sorry your machine restarted because of an error". 

This was with "GPU rasterization" _disabled_ in Version 63.0.3239.9
So far disabling GPU rasterization has worked this morning
I forgot to mention in https://bugs.chromium.org/p/chromium/issues/detail?id=773705#c38 that I had Slack (an Electron app) open at the same time. I'm not sure how to disable "GPU rasterization" in Slack/Electron apps.

So this afternoon I've been running Chrome Version 63.0.3239.9 with "GPU rasterization" disabled, but haven't been running Slack (to try and work out whether the system crash earlier was Slack or Chrome).

So far, no glitches, no crashes. 

My rough conclusion thus far therefore is that Chrome Version 63.0.3239.9 with "GPU rasterization" disabled is OK.

As a reminder of my setup, details in https://bugs.chromium.org/p/chromium/issues/detail?id=772735#c8
Labels: M-63
Further update based on another day of testing with 63.0.3239.9; no Slack app running.

With GPU rasterization on "Default" - consistently causes my machine to switch into a lagging/slow state (particularly noticeable in other apps) which ultimately requires me to restart my machine, but as yet I haven't seen glitches in Chrome itself.

With GPU rasterization "Off" - no glitches and doesn't appear to cause any speed problems in other apps. i.e. this is the current "best" state.

This seems consistent with the fact that:

* 63.0.3239.9 with GPU rasterization on "default" causes problems on my hardware
* Slack (an Electron app which ultimately uses Google Chrome) also causes problems on my hardware (because I guess it defaults to "GPU rasterization"?)
Project Member Comment 43 by bugdroid1@chromium.org, Oct 21
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bb354ab52392a11204cd3fc2d443d6ba5cbb87ed

commit bb354ab52392a11204cd3fc2d443d6ba5cbb87ed
Author: Eric Karl <ericrk@chromium.org>
Date: Sat Oct 21 23:16:26 2017

Blacklist GPU Raster / Canvas on NVidia GPU macs with High Sierra

These systems have bad graphical glitches, and we'd like to get a fix in for M62.

TBR=vmiura@chromium.org as this is a very small change we discussed, and the next
stable cut is on Tuesday. I want to get a day or two of Canary coverage over the
weekend so we can merge with higher confidence.

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: I5c4459b5658a7540424d2ad2193bb5b3601b4cad
Reviewed-on: https://chromium-review.googlesource.com/732325
Commit-Queue: Eric Karl <ericrk@chromium.org>
Reviewed-by: Eric Karl <ericrk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#510695}
[modify] https://crrev.com/bb354ab52392a11204cd3fc2d443d6ba5cbb87ed/gpu/config/software_rendering_list.json

Building on my last comment (https://bugs.chromium.org/p/chromium/issues/detail?id=773705#c42)

I will just note that, despite no further glitches, running things in this state is causing Chrome to be very slow when I have a number of tabs open, large pages etc. It also seems to cause problems in my Hangouts calls - other participants on the call struggle to hear me because my voice cuts out for them (which we've work out can be nothing other than Chrome struggling to keep up)
paul@, thank you for your very thorough testing. Sorry to hear that disabling GPU raster is leading to performance issues. Note that this is a temporary solution for M62  (better than crashing or having contents not display). I hope that this bug will either be fixed by Apple soon, or we can find a better workaround in the M63 timeframe.
Cc: abdulsyed@chromium.org
Labels: Merge-Request-62
abdulsyed@, the change in #43 is the workaround we discussed on Thursday. manoranjanr@ and I both confirmed that the issue does not repro after this change (or becomes very difficult to repro), and one user (paul@...) has confirmed this as well. I'd like to merge this into this week's M62. Thanks!
Project Member Comment 47 by sheriffbot@chromium.org, Oct 23
Labels: -Merge-Request-62 Merge-Review-62 Hotlist-Merge-Review
This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Mid 2012 MBP Retina, full patched everything, High Sierra.

Google Sheets becomes unusable soon after I launch Chrome (I normally have 5+ sheets open).

Today I decided to try launching chrome with --disable-gpu-rasterization to see if that fixes my problem on Chrome. Today for the first time Slack (app on OSX) has started expressing the same rendering issue I've been seeing on Chrome since approximately my High Sierra install date (2w). Chrome hasn't expressed the bug yet since I launched it with GPU Rast disabled.

about:gpu output attached.

thanks

gpu.html
51.2 KB View Download
FWIW I'm still seeing the rendering issue on GSheets, "--disable-gpu-rasterization" did not fix it. Screen shot attached.
Finally note that the bug occurs in Incognito mode as well.

Also, since I have it, here is the console log from Chrome this session (GPU rasterization disabled, includes time of screen shot):


2017-10-23 10:49:44.063 Google Chrome[5434:719717] *** Owner supplied to -[NSTrackingArea initWithRect:options:owner:userInfo:] referenced a deallocating object. Tracking area behavior is undefined. Break on NSTrackingAreaDeallocatingOwnerError to debug.
[5458:36107:1023/104945.708244:ERROR:adm_helpers.cc(62)] Failed to query stereo recording.
[5434:45059:1023/104946.553357:ERROR:service_manager.cc(156)] Connection InterfaceProviderSpec prevented service: content_browser from binding interface: content::mojom::Child exposed by: nacl_loader
[5462,2453111616:10:49:46.610995] Native Client module will be loaded at base address 0x00006d8f00000000
[5434:775:1023/104947.300204:ERROR:display_info_provider_mac.cc(30)] Not implemented reached in virtual void extensions::DisplayInfoProviderMac::UpdateDisplayUnitInfoForPlatform(const display::Display &, extensions::api::system_display::DisplayUnitInfo *)
[5509:39435:1023/105119.130761:ERROR:render_media_log.cc(30)] MediaEvent: MEDIA_ERROR_LOG_ENTRY {"error":"FFmpegDemuxer: data source error"}
[5509:775:1023/105119.131005:ERROR:render_media_log.cc(30)] MediaEvent: PIPELINE_ERROR PIPELINE_ERROR_READ
2017-10-23 10:55:27.736 Google Chrome Helper[5468:720829] Couldn't set selectedTextBackgroundColor from default ()
2017-10-23 10:56:00.669 Google Chrome Helper[5470:720889] Couldn't set selectedTextBackgroundColor from default ()
2017-10-23 11:01:50.283 Google Chrome Helper[5506:722322] Couldn't set selectedTextBackgroundColor from default ()
2017-10-23 11:12:59.138 Google Chrome Helper[5446:719993] Couldn't set selectedTextBackgroundColor from default ()
objc[5434]: Class FIFinderSyncExtensionHost is implemented in both /System/Library/PrivateFrameworks/FinderKit.framework/Versions/A/FinderKit (0x7fff8efcaa70) and /System/Library/PrivateFrameworks/FileProvider.framework/OverrideBundles/FinderSyncCollaborationFileProviderOverride.bundle/Contents/MacOS/FinderSyncCollaborationFileProviderOverride (0x11a77fcd8). One of the two will be used. Which one is undefined.
2017-10-23 11:17:08.655 Google Chrome Helper[5503:721971] Couldn't set selectedTextBackgroundColor from default ()
2017-10-23 11:19:37.222 Google Chrome Helper[5480:721363] Couldn't set selectedTextBackgroundColor from default ()
2017-10-23 11:26:15.726 Google Chrome Helper[5471:720930] Couldn't set selectedTextBackgroundColor from default ()
2017-10-23 11:34:11.193 Google Chrome Helper[5495:721812] Couldn't set selectedTextBackgroundColor from default ()
2017-10-23 11:49:42.274 Google Chrome Helper[6414:853962] Couldn't set selectedTextBackgroundColor from default ()


Chrome Rendering Issue with GSheets .png
92.6 KB View Download
Is this also need a merge to M63? If yes, please request a merge to M63. Thank you.
With GPU rasterization disabled, things have been way more stable for a few days, with zero issues with pages deconstructing themselves on scrolling as they used to.

Just ran into a video issue now though, and not sure if it's related.  A YouTube video had some issues with playback flickering - this happens occasionally with YouTube videos.  Sorry for the weird video - but you can see the flickering artifacts here: https://www.youtube.com/watch?v=Zo-fcWWd8OI

about:gpu is in general way less busy these days.  Just a few log entries:

[423:55303:1022/181239.784879:ERROR:vt_video_decode_accelerator_mac.cc(782)] : Illegal attempt to decode without IDR. Discarding decode requests until next IDR.
[423:62971:1023/100413.859500:ERROR:vt_video_decode_accelerator_mac.cc(782)] : Illegal attempt to decode without IDR. Discarding decode requests until next IDR.
[423:84347:1023/102132.913039:ERROR:vt_video_decode_accelerator_mac.cc(782)] : Illegal attempt to decode without IDR. Discarding decode requests until next IDR.

Now running on Chrome 62.0.3202.62, with mid-2012 Retina Macbook Pro.
Labels: Merge-Request-63
Thanks for the continued reports:

ram@, can you try also disabling accelerated canvas (in about:flags, set "Accelerated 2D canvas" to disabled, or just run with --disable-accelerated-2d-canvas). The patch I'm landing for M62 does this as well as disabling GPU rasterization.

david.b...@, thanks for the report. I believe this is a different issue, we've seen this in the past on pre-high-sierra. I'll continue investigating.

Cc: schenney@chromium.org hdodda@chromium.org
 Issue 773354  has been merged into this issue.
Blocking: 777590
Labels: -Merge-Request-63 Merge-Approved-63
Approving merge to M63. Will revisit M62 tomorrow if all looks good after Dev release tomorrow. 
ericrk@ that seems to have done the trick - I'm running with both GPU rasterization and accel-2d-canvas disabled and that seems to do the trick.
Gracias hombre!
Here's an video of a WebGL canvas after returning to it 20 minutes later. No context lost messages, just the view starts flickering horribly on High Sierra.  Every other frame of mouse movement.  I'd say it's a bug in double-buffering.  OSX switches the backbuffer id after presenting, unless you pass render textures to the WebGL view. 


HighSierraWebGLFlashing.mov
116 KB Download
Thus happens in Native OpenGL apps, so it’s likely an Apple driver bug specific to Nvidia 650m/750m (possibly earlier MB Pros too).
alec@, given the way Chrome handles presenting WebGL (rasterizing to a texture and compositing that with the page), I'd be surprised if it was an issue with double buffering. Our final presentation to screen always uses Apple's Core Animation layer.

Do you have a WebGL app which will reliably (or semi reliably) trigger these issues? I'd like to investigate more.
Yes.  figma.com exhibits this problem.  That’s what I captured the video from.  Slack’s animated gif shows garbage in preview, or black in fullscreen mode.  Video previews are also black.  So could be a scaled glBlitFramebuffer bug too.
Project Member Comment 62 by bugdroid1@chromium.org, Oct 24
Labels: -merge-approved-63 merge-merged-3239
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/24d15ae9c0cb8e0eb3b626c3b8ec40eaac6b04f6

commit 24d15ae9c0cb8e0eb3b626c3b8ec40eaac6b04f6
Author: Eric Karl <ericrk@chromium.org>
Date: Tue Oct 24 19:10:21 2017

Blacklist GPU Raster / Canvas on NVidia GPU macs with High Sierra

These systems have bad graphical glitches, and we'd like to get a fix in for M62.

TBR=and the next, ericrk@chromium.org, vmiura@chromium.org as this is a very small change we discussed
stable cut is on Tuesday. I want to get a day or two of Canary coverage over the
weekend so we can merge with higher confidence.

(cherry picked from commit bb354ab52392a11204cd3fc2d443d6ba5cbb87ed)

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: I5c4459b5658a7540424d2ad2193bb5b3601b4cad
Reviewed-on: https://chromium-review.googlesource.com/732325
Commit-Queue: Eric Karl <ericrk@chromium.org>
Reviewed-by: Eric Karl <ericrk@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#510695}
Reviewed-on: https://chromium-review.googlesource.com/735524
Cr-Commit-Position: refs/branch-heads/3239@{#186}
Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578}
[modify] https://crrev.com/24d15ae9c0cb8e0eb3b626c3b8ec40eaac6b04f6/gpu/config/software_rendering_list.json

Labels: -Merge-Review-62 Merge-Approved-62
Approving merge for M62, branch:3202, as well (to avoid any last minute merge conflicts). However, let's still manually verify this in M63 Dev release tomorrow, and if there are issues, we can revert it.
I have now managed to repro what I think is something related _without_ Google Chrome.

The repro involves ensuring that I'm using any program that causes the Macbook Pro to switch to using the discrete graphics card (NVidia GeForce GT 750M for me)

Then I switch to a finder window, and hit spacebar (for a quick preview) of a specific jpeg image (which I can share privately if required) and it renders as attached, i.e. full of artefacts/glitches.

Does anyone on this thread have a line to Apple where this can be reported? 
Screen Shot 2017-10-24 at 23.15.27.png
8.6 MB View Download
I have an OSX NSOpenGLView based app that worked and wasn't glitchy anymore when I removed NSOpenGLPFADoubleBuffer on High Sierra.  You have to add an explicit glFlush wherever you used [glView flushBuffer] previously, since that call doesn't flush for the single-buffer case.  

With double buffering on Sierra on both the Intel Iris Pro GPU and Nvidia 750m GPU, rendering would glitch out.  I suspected this from the flashing video I presented above, and it also looks like the row bytes (or row pixel count is incorrect on one of the double buffers) when resizing the view.  That causes the content to shift on each scanline.

My concern is that disabling GPU rasterization doesn't go far enough, since I saw some glitches on the Intel part, but video/animated GIF was correct.  Hope that helps narrow things down.


Project Member Comment 66 by bugdroid1@chromium.org, Oct 24
Labels: -merge-approved-62 merge-merged-3202
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c180321904321d3504c26f22c27fc1520f34e33f

commit c180321904321d3504c26f22c27fc1520f34e33f
Author: Eric Karl <ericrk@chromium.org>
Date: Tue Oct 24 23:00:08 2017

Blacklist GPU Raster / Canvas on NVidia GPU macs with High Sierra

These systems have bad graphical glitches, and we'd like to get a fix in for M62.

TBR=and the next, ericrk@chromium.org, vmiura@chromium.org as this is a very small change we discussed
stable cut is on Tuesday. I want to get a day or two of Canary coverage over the
weekend so we can merge with higher confidence.

(cherry picked from commit bb354ab52392a11204cd3fc2d443d6ba5cbb87ed)

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: I5c4459b5658a7540424d2ad2193bb5b3601b4cad
Reviewed-on: https://chromium-review.googlesource.com/732325
Commit-Queue: Eric Karl <ericrk@chromium.org>
Reviewed-by: Eric Karl <ericrk@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#510695}
Reviewed-on: https://chromium-review.googlesource.com/736859
Cr-Commit-Position: refs/branch-heads/3202@{#738}
Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098}
[modify] https://crrev.com/c180321904321d3504c26f22c27fc1520f34e33f/gpu/config/software_rendering_list.json

Cc: ranjitkan@chromium.org
Labels: TE-Verified-63.0.3239.18 TE-Verified-M63 TE-Verified-M64 TE-Verified-64.0.3249.0
Rechecked this issue on Mac 10.13 Beta (17A360a) with chrome version 63.0.3239.18 and Canary version 64.0.3249.0, 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 (Screen Shot Attached)

Note: Was able to replicate the issue on canary version# 64.0.3247.0 (Screen shot attached)

Adding TE-verified labels for M63 and M64
No GPU Glitch.png
857 KB View Download
Gpu Glitch.png
678 KB View Download
FYI - I've also raised a bug with Apple regarding the non-Chrome-based repro mentioned in https://bugs.chromium.org/p/chromium/issues/detail?id=773705#c64
Labels: TE-Verified-M62 TE-Verified-62.0.3202.75
Rechecked this issue on Mac 10.13 Beta (17A360a) with chrome version 62.0.3202.75 and , merge 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.

Adding TE-Verified labels for M62
Same problem with my iMac late 2013 27" (nvidia GT755M).

How can i fix this problem? I can't install gfxCardStatus because it works only with macbook product.


Hi boschettosandro@, the issue should be fixed for you once you get the latest version of Chrome 62 (should be coming out this week I think). In the meantime, you can navigate to "about:flags" in Chrome, and set the following settings:

"Accelerated 2D Canvas": Set to disable
"Gpu Rasterization": Set to disabled
Can I just ask you to confirm what you mean by "fixed"?

My understanding is that the "fix" automatically disables Accelerated 2D Canvas and Gpu Rasterization for affected hardware. 

But does this not mean those of us who have this hardware therefore experience a performance regression?

i.e. this feels more like a workaround until Apple have fixed the actual issue, no?

That being the case, is someone from the Chrome team following up with Apple?
Re #72, you're correct. The "fix" should resolve most visual issues, but comes with a performance hit. We've followed up with Apple and reported these issues. We plan to restore these performance features when a fix makes its way to OSX.

Also, thanks very much for filing the additional issue (non-Chrome) with Apple.
Re #73 - thanks for confirming. Is there a tracking Chrome issue for the real fix post Apple's fix? Would be useful to have such an issue so that people can follow along and see what progress there is from Apple's side. 
Blockedon: 778770
Blocking: 779168
Blocking: 777457
 Issue 779343  has been merged into this issue.
Following up on #73 - following the "fix" (#71) I've had to manually enable 2D acceleration and GPU rasterization because otherwise Google Sheets on my system is unusable (I remember seeing a post to this effect in a linked issue). So I think this adds weight to my comments in #74 that we need a proper fix from Apple so that the "fix" this issue refers to can be reverted and these features be enabled by default.
If it's any help, I've seen similar corruption, on High Sierra, on a MacBook Pro Late 2013 with a 750M. I've seen it in: Slack, Atom.io, Safari. I've got some log files of the error messages reported by the GPU. Here is an example:

Mon Oct 30 12:00:55 2017

Event:               GPU Reset
Date/Time:           Mon Oct 30 12:00:55 2017
Application:         WindowServer
Path:                /System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/Resources/WindowServer
Tailspin:            /Library/Logs/DiagnosticReports/gpuRestart2017-10-30-120055.tailspin
GPUSubmission Trace ID: 0
OS Version:          Mac OS X Version 10.13 (Build 17A405)
Graphics Hardware:   NVIDIA GeForce GT 750M
Signature:           1f

Report Data:

NVDA(DMA): Channel exception! Exception type = 0x1f Access Violation Error (MMU Error 2)
Channel Info: [9, 0xa, 0x8, 0x25611]
Version Info: [com.apple.GeForce, 10.2.4, 0x4e554e, 21320326, 355.11.10.10.10.160, 1]
MMU Error: FAULT_PTE at 0x538fe0000

Resource Manager Info:
 4443564e 000000a8 6b6c36e1 6297e245 00000001 00000014 d3793533 46d3a4a6
 4614f297 e71edccf 00088301 00000074 149a030a 820a0a00 03180713 01900150
 923d0a01 380a3a13 00000024 0000000e 0000e001 00000f49 00000001 00000b49
 00000000 00030447 000000ff 000000ff 000000ff 000000ff 000000ff 000000ff
 13c2220a 1000081f 80a81800 200bf798 301f280a 50003803 a39cdf98 4007d192
 01480280 4443564e

I initially thought it was a hardware fault.

Blocking: 779318
Labels: -M-62 -M-63
 Issue 779318  has been merged into this issue.
Hi, 
I experience the same symptoms on my MacBook Pro (Retina, 15-inch, Mid 2014) with NVIDIA GeForce GT 750M 2 GB
Intel Iris Pro 1536 MB

I tried using the latest NVIDIA Web Driver, but it did not help.

I also see some glitches and flickering when using Parallels Desktop so it's not just a chromium problem.
While this forum might be a bit over my head, I know enough to know  that the above issue fits with my experience...  I have a MacBook Pro (Retina, 15-inch, Early 2013)... NVIDIA GeForce GT 650M 1 GB.

Google Chrome seems most affected, but I have had some graphic rendering problems with Firefox.  While some rendering problems take a while to develop (Google Sheets/Docs/Drive), I am able to replicate issues fairly quickly in WordPress with the DIVI builder.  Usually after 15 minutes or so, the builder windows will either appear completely blank so that I cannot see the content or toolbars, OR... I will get the wonderful barbershop mirror effect with many offset copies of the content.

The problem DID NOT appear in any noticeable form to me until the release of High Sierra... which also coincided with a google chrome release... unfortunate timing for me to trouble shoot.  I'm fairly certain that this is more of an apple problem, but would REALLY like for it to be solved.  I NEED my chrome profiles to use for various client log in sessions.


yes- and the issue doesn't seem to be improving
Maybe this isnt productive, but frankly I don't care, especially as the author of the ticket.

This was Apple's regression, a highly concerning one given where the flaw exists and that it was remotely possible to introduce. The workaround change is an unreasonable compromise even temporarily. This has a ripple effect to a vast number of applications that rely on the technology. There should be an @apple.com email address in this thread. If there is no fix for this in the next point release of macOS, I have no faith in Apple's commitment to quality, let alone macOS in general.

I'd like to see transparency from Google about how many calls are being made to Apple and how frequently. I want to know what Apple has said, if anything. I want to see the ticket in Apple's bug tracking software, I want to know when it was created and I want to know if it was punted past any subsequent release.

This is 100% unnaceptable. It's been 20 days. Enough is enough.
This is definitely an Apple software issue, so I don't think we can expect Google to fix their errors. The issue is persistent among other applications.
I'm in touch with Apple and NVIDIA, my cases with both have been escalated and I'm awaiting a reply from their engineers. Suggest everyone else who is having this issue do the same!
In response to #89 - I've done the same. 

Incidentally, this problem is not fixed in 10.13.1 Beta (17B42a) - I upgraded today. If anything it's slightly worse (although I can't discount there being something else at play in the beta)
Project Member Comment 91 by bugdroid1@chromium.org, Nov 2
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a28eb737c4c9424d7656ada19b688af854777968

commit a28eb737c4c9424d7656ada19b688af854777968
Author: Justin Novosad <junov@chromium.org>
Date: Thu Nov 02 01:23:34 2017

Allow blacklisting of use of GpuMemoryBuffers as render targets.

Disable this on macOS 10.13 when NVIDIA GPUs are in use. Based on
experiments with WebGL, it strongly seems that the bugs introduced in
this OS release are not tied to GPU rasterization or accelerated 2D
canvas, but rather caused by rendering into IOSurfaces via OpenGL.

Re-enable accelerated 2D canvas and GPU rasterization on this
configuration.

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: I8422a84dd65b0db8c63af5398547da7366217274
Reviewed-on: https://chromium-review.googlesource.com/745966
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Justin Novosad <junov@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Eric Karl <ericrk@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
Cr-Commit-Position: refs/heads/master@{#513360}
[modify] https://crrev.com/a28eb737c4c9424d7656ada19b688af854777968/cc/DEPS
[modify] https://crrev.com/a28eb737c4c9424d7656ada19b688af854777968/content/browser/compositor/gpu_process_transport_factory.cc
[modify] https://crrev.com/a28eb737c4c9424d7656ada19b688af854777968/content/renderer/pepper/ppb_graphics_3d_impl.cc
[modify] https://crrev.com/a28eb737c4c9424d7656ada19b688af854777968/content/renderer/pepper/ppb_graphics_3d_impl.h
[modify] https://crrev.com/a28eb737c4c9424d7656ada19b688af854777968/gpu/command_buffer/service/feature_info.cc
[modify] https://crrev.com/a28eb737c4c9424d7656ada19b688af854777968/gpu/config/gpu_driver_bug_list.json
[modify] https://crrev.com/a28eb737c4c9424d7656ada19b688af854777968/gpu/config/gpu_driver_bug_workaround_type.h
[modify] https://crrev.com/a28eb737c4c9424d7656ada19b688af854777968/gpu/config/software_rendering_list.json
[modify] https://crrev.com/a28eb737c4c9424d7656ada19b688af854777968/third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridge.cpp
[modify] https://crrev.com/a28eb737c4c9424d7656ada19b688af854777968/third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridge.h
[modify] https://crrev.com/a28eb737c4c9424d7656ada19b688af854777968/third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridgeTest.cpp
[modify] https://crrev.com/a28eb737c4c9424d7656ada19b688af854777968/third_party/WebKit/Source/platform/graphics/DEPS
[modify] https://crrev.com/a28eb737c4c9424d7656ada19b688af854777968/third_party/WebKit/Source/platform/graphics/gpu/DEPS
[modify] https://crrev.com/a28eb737c4c9424d7656ada19b688af854777968/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.cpp

Re 91; I'm confused as to what this means. Is it saying that the disabling of "Accelerated 2D canvas" and "GPU Rasterization" was the _wrong_ fix?
#92, yes, that's correct. The issue behaves slightly differently on macOS 10.13.1 for me, but is still very much a thing on both the OS drivers and the latest from NVIDIA (378.10.10.10.20.107). Tested in several Electron apps, Chrome Stable (62) and Canary (64). Happy to provide detailed logs from my system if necessary. 

error	18:18:32.684774 +0100	WindowServer	[ERROR] - Unknown CGXDisplayDevice: 0x41dc9d00

fault	18:18:32.708382 +0100	kernel	IOReturn IOAccelSurface2::surface_unlock_options(enum eLockType, uint32_t): surface is not locked.

fault	18:22:04.481778 +0100	kernel	void IOAccelFenceMachine::fence_timeout(IOTimerEventSource *): GeForce GT 650M prodding blockFenceInterrupt

#92 as we've been diagnosing this graphics driver bug we've come to a better understanding of what's likely wrong. We think at this point that the bug is related to a very specific operation -- rendering to cross-process graphics resources (IOSurfaces) using the OpenGL API. The disabling of accelerated 2D canvas and GPU rasterization happened to avoid this operation, but in Chrome it's possible to leave those features enabled and have the rendering occur to a regular OpenGL texture instead of an IOSurface. This is what https://chromium-review.googlesource.com/745966 does. It seems to regain all the performance and still avoid the bug.

I wanted to wait to post here until the fix had reached Canary but unfortunately it missed today's build. Anyone who can reproduce this, please test with tomorrow's Canary (any build number after 513360) and tell us whether the bug appears to be fixed.

We will aim to merge this fix back to Chrome 63 (currently in Beta). Merging it back to M62 may be a bit risky, so we'll probably ask affected folks to upgrade to Beta temporarily to get back the performance that was lost with the original workaround.

Labels: Merge-Request-63
Requesting merge of https://chromium-review.googlesource.com/745966 to M63.

The backport of this fix has been reviewed in:
https://chromium-review.googlesource.com/750327

Despite the fact that it's more code, we think it is a lower-impact workaround than the one that's already been merged back. Some of the affected code paths changed compared to top-of-tree, but we feel this is a safe change. It has been tested locally on the affected hardware. More testing is still ongoing.

https://chromium-review.googlesource.com/745966 has not made it to Canary yet, but if we receive approval to merge back, we'll wait until it's baked there for a few days (and, ideally, until customers have helped confirm the workaround).

#93 #94 - thanks for the quick responses. Will wait for this to hit the dev channel on Chrome and then report back.

So just to clarify where we are: 

* this is ultimately an OS X bug in 10.13 with NVIDIA chipsets specifically
* Chrome has a "complete" workaround (#91 with commentary in #94)
* but this doesn't preclude other applications triggering the issue (which would then presumably lead to slowness/other symptoms that people reported when Chrome triggered the issue)

Is that the right conclusion?


#96 yes, it is a bug in macOS 10.13 on NVIDIA chipsets.

We believe the workaround in #91 is solid, but we still don't know exactly what the bug was, so can't state that with 100% certainty.

Yes, other applications can still potentially trigger the bug.

Project Member Comment 98 by sheriffbot@chromium.org, Nov 3
Labels: -Merge-Request-63 Merge-Review-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
#94 over night I seemed to get a Mac OS X Beta update. 

So this morning I installed Chrome Canary to see where things stand. 

Not sure how I can tell what Canary build I have? It looks like it contains the fix mentioned in #91 because "accelerated 2D canvas" and "GPU Rasterization" are enabled by default in about:flags.

So my setup is now:

Chrome Version 64.0.3257.0 (Official Build) canary (64-bit)
OS X 10.13.2 Beta (17C60c)

Lots of rendering glitches under this setup: pages not being rendered at all, switching between tabs has one tab rendering as if it were another... I can post more details if required, but wanted to make sure I'm running the right builds etc first.
paul@: it's unfortunate that both the OS and browser changed at the same time.

Could you please launch the browser from the command line with --disable-gpu-rasterization and tell us whether that appears to address the rendering glitches? It seems clear that we don't understand exactly what the driver bug is. But perhaps it's regressed even more badly in the 10.13.2 beta. (We'll be testing more on this side but need feedback from someone who easily reproduces this)

kbr@: yes, unfortunate indeed!

> Could you please launch the browser from the command line with --disable-gpu-rasterization and tell us whether that appears to address the rendering glitches?

Yes, it appears to. Without that flag I get the glitches almost immediately (seems to be particularly triggered by Hangouts + Twitter + YouTube...). With the flag, no issues so far.
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
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
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
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
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
Blocking: 781598
Blocking: -775202
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
#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
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
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?
about:gpu content wasn't attached in the last comment.

ahh, sorry, attached here
gpu.htm
58.3 KB View Download
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.
Sign in to add a comment