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

Issue 805101 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

cc: Long UIResource requests during tree activation (on Mac)

Project Member Reported by vmi...@chromium.org, Jan 23 2018

Issue description

Chrome Version: 66.0.3329.1
OS: OSX 10.12.6 & 10.13.2 tested

What steps will reproduce the problem?
(1) Open https://colab.research.google.com/notebook#fileId=14IvSaLNrBYrMLwjFTcvSufJWGIKPNFs_
(2) Resize browser window such that code blocks in the Colab Notebook don't fit and get horizontal scroll bars.
(3) Scroll up & down.

I first noticed the issue on a 2012 MBP Retina with 8GB of RAM, with a Colab Notebook I was working on, but and had a harder time reproducing on a 16GB MBP.  The linked example Notebook above adds a lot of extra code blocks which also provoke the issue on a 2015 MBP with 16GB RAM, though it is still much faster on the latter.

Extra notes are in this shared doc: https://docs.google.com/document/d/159ha6FsmtoawZola13vlf5iRR4chvDl5YcP0Uzb6lys

The CC thread is mostly waiting for GPU Memory Buffer and GPU Command Buffer IPCs, while GPU thread is pegged creating and uploading the UI resources.
 
colab_page.png
135 KB View Download
cc_thread.png
78.7 KB View Download
gpu_thread.png
35.8 KB View Download
trace_colab_mbp_2012.json.gz
8.4 MB Download
trace_colab_mbp_2015.json.gz
8.2 MB Download
When we switched to using IOSurfaces for all resources on Mac, I didn't notice that using them on the client side was expensive because that cost was dramatically offset by other CPU and GPU power savings.

We should change this to do one-copy to an anonymous-GMB backed GLImage, as we did with IOSurface-backed GPU rasterization resources on Mac.

Some further things worth investigating:

1. It may be worth investigating if doing one-copy anonymous-GMB GLImages has a better power profile than zero-copy. This is low priority b/c SW raster is so rare.

2. We may also want to investigate service-side reuse of IOSurfaces to avoid the costs of creating, deleting, and CGLTexImageIOSurface-ing IOSurfaces.

3. Mac team also really should stop calling into these private APIs to draw scrollbars, etc -- we already have code to draw them in Skia for MacViews, we just need to hook that up.
(also point 3 in #1 will allow further sandbox lockdown, avoid messiness in impl-side-scrolling, and generally make for less sadness)

Comment 3 by vmi...@chromium.org, Jan 23 2018

> 1. It may be worth investigating if doing one-copy anonymous-GMB GLImages has a
> better power profile than zero-copy. This is low priority b/c SW raster is so
> rare.

I think we are doing that in this case; rather than zero-copy we're using TexStorage2DImageCHROMIUM + TexSubImage2D.  Though, we're not using staging GMBs like for one-copy raster.

This should be asynchronous, but it looks like there are a lot of Flushes & WaitForTokens happening (nearly one per TexStorage2DImageCHROMIUM), so it would be interesting to see why that is.  Rather than explicit, it may be that we're just running out of transfer buffer space.  We don't scale that up very aggressively to prevent stalls.

The service side TexSubImage2D are still slow (esp. on the GT 650M on my 2012 MBP).

> 3. Mac team also really should stop calling into these private APIs to
> draw scrollbars, etc -- we already have code to draw them in Skia for
> MacViews, we just need to hook that up.

It would be interesting to understand what causes us to invalidate and re-upload all these resources.  (a) They should not be changing and (b) They're mostly out of view.

Sign in to add a comment