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

Issue 646195 link

Starred by 2 users

Issue metadata

Status: Duplicate
Merged: issue 672929
Owner: ----
Closed: Jun 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Feature



Sign in to add a comment

Mus+Ash: Need raster and/or draw occlusion

Project Member Reported by fsam...@chromium.org, Sep 12 2016

Issue description

Chatting with Antoine, we might want to consider two metrics:

1. How many browser windows can we open in Mus+Ash versus Chrome OS today until UI starts to disappear on device?

2. How much GPU memory do we use with a browser window + 4K wallpaper on Mus+Ash versus Chrome OS?

The general concern is we do not do raster or draw occlusion culling on Mus+Ash currently.

Raster happens in the client in tadpole and so we would need a mechanism to partially occlude surfaces and tell clients about their visible region.

For draw, we do not currently do any kind of occlusion culling. Occlusion culling could be added into SurfaceAggregator.
 

Comment 1 by piman@chromium.org, Sep 13 2016

To clarify, one of the other concerns about draw occlusion is that without it, performance can suffer a lot. For example, today (pre-MUS) a full-screen window doesn't need to draw the background (possibly expensive if it's a large image) every time something changes in the page. This is doubly important for e.g. full-screen videos.

Comment 2 by sky@chromium.org, Sep 13 2016

I seem to remember having lots of performance issues before occlusion culling. I suspect we need it to launch.
So what kind of work would need to be done in SurfaceAggregator? If we skip occluded DrawQuads, then we can skip waiting on sync points, but we will still upload textures to the GPU? Will skipping DrawQuads and sync points give us the wins we want/need?
A possible third component of this bug is to implement some occlusion detection code in the window server. The window server does not use LayerTreeHost/LayerTreeHostImpl. Instead it generates a CompositorFrame of SurfaceDrawQuads directly. Thus, we lose out on all occlusion culling code in cc today in the window server. The window server knows when a SurfaceDrawQuad is entirely occluded and can mark the window as not visible. 

Alternatively this could be the responsibility of the display compositor and CompositorFrameSinks. We should probably stop BeginFrames to windows that are not visible on screen?

This probably also fits in with evicting CompositorFrames: https://bugs.chromium.org/p/chromium/issues/detail?id=646242

Some design work is required here as well. 

Comment 5 by piman@chromium.org, Sep 13 2016

Skipping DrawQuads would solve opaque overdraw performance issues (the ones I mentioned in #1), but wouldn't do anything to memory, or anything upstream of the draw (uploads, etc.), which could be handled at a higher level (IsVisible).

BTW, I'm not sure there's a lot of value in skipping the sync token waits (it's an ordering primitive, not a blocking wait), so unless it's trivial I would probably punt. Not waiting will not skip the uploads or other commands necessary to produce the resources for example (it's just that they may happen out-of-order with the draw commands).
I just had a chat with Antoine about copy requests and draw occlusion. We cannot skip DrawQuads if there is a copy request on a surface.
Labels: Proj-Mustash
Components: Internals>MUS
Blocking: 601863
Labels: displaycompositor
Status: Available (was: Unconfirmed)
Components: Internals>Compositing
Labels: Type-Feature
Cc: weiliangc@chromium.org
Cc: varkha@chromium.org
Mergedinto: 672929
Status: Duplicate (was: Available)
Blocking: -601863
Components: -Internals>MUS Internals>Services>WindowService
Components: -MUS

Sign in to add a comment