Issue metadata
Sign in to add a comment
|
Mus+Ash: Need raster and/or draw occlusion |
||||||||||||||||||||||||
Issue descriptionChatting 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.
,
Sep 13 2016
I seem to remember having lots of performance issues before occlusion culling. I suspect we need it to launch.
,
Sep 13 2016
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?
,
Sep 13 2016
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.
,
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).
,
Sep 13 2016
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.
,
Oct 4 2016
,
Oct 4 2016
,
Dec 1 2016
,
Dec 3 2016
,
Jan 23 2017
,
Jan 26 2017
,
Apr 19 2017
,
May 3 2017
,
May 23 2017
,
Jun 12 2017
,
Jun 13 2017
,
Feb 26 2018
,
Feb 26 2018
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by piman@chromium.org
, Sep 13 2016