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

Surface synchronization: Consider interaction with BeginFrameSource

Project Member Reported by fsam...@chromium.org, May 13 2017

Issue description

SurfaceDependencyTracker currently ALWAYS observes the BeginFrameSource of the first display. If the first display goes away, then synchronization breaks and we crash on tear down :D This is obviously bad.

Generally, it's desirable to align deadlines to vsyncs, and make them a function of # of BeginFrames as opposed to arbitrary milliseconds because we expect clients to produce CompositorFrames once per BeginFrame in the ideal case.

There are two unanswered questions:

1. What happens if the first display goes away?
2. Should we really ALWAYS be observing BeginFrames?

For 1, I think the answer is we arbitrarily pick another display for BeginFrames. We can perhaps be more clever in the future, but there's no pressing need for cleverness at the moment.

For 2, I think (in consultation with enne@) we don't want to forward BeginFrames of another observer to SurfaceDependencyTracker because always observing a BeginFrameSource has side effects.

Continuously observing a BeginFrameSource causes the current BeginFrameArgs to be updated, and if a client doesn't response then it will receive a "MISSED FRAME" signal on the next BeginFrame it does receive, and that can influence scheduling inadvertently. By continuously observing a BeginFrameSource, scheduling heuristics could be thrown off with a bad signal. 

However, with BeginFrameAcks, an observer is expected to produce a CompositorFrame or a BeginFrameDidNotSwap: neither of which make sense for SurfaceDependencyTracker.

I think the easiest solution here is to keep SurfaceDependencyTracker a BeginFrameObserver, but it should be told when cc::Displays come and go so that it knows when to start observing a BeginFrameSource and when to stop observing a BeginFrameSource.
 

Comment 1 by eseckler@google.com, May 13 2017

Maybe it should get its BFS like CFSSupport from the FrameSinkManager?

I wouldn't worry about the BeginFrameAcks for now, as our latest discussions seem to move away from per-observer tracking to per-surface tracking. I think we'll eventually decouple them from BeginFrameSources completely.

I think it would also be good not to observe BeginFrames when not necessary, i.e. while no pending CompositorFrames exist. Otherwise you may prevent the BFS from going idle and thus risk preventing entering power saving states when the system is otherwise idle.

Comment 2 by enne@chromium.org, May 18 2017

Status: Available (was: Untriaged)
Cc: varkha@chromium.org
Cc: fsam...@chromium.org tguilbert@chromium.org
 Issue 726787  has been merged into this issue.
As eseckler@ mentioned, always observing a BeginFrameSource introduces a bunch of overhead. We need to avoid that. I have a patch in flight.
Cc: vmp...@chromium.org
Project Member

Comment 7 by bugdroid1@chromium.org, May 30 2017

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

commit 505078044cfca8e67070b4daed6e6157d7641774
Author: fsamuel <fsamuel@chromium.org>
Date: Tue May 30 18:21:01 2017

SurfaceDependencyTracker: Only observe BeginFrames if a deadline is needed

Always observing deadlines could potentially prevent the CPU from idling because
that requires a timer to always fire. This CL only observes BeginFrames if there are
unresolved dependencies.

A new object type, SurfaceDependencyDeadline is introduced that
observes BeginFrames within its scope and reports back to
SurfaceDependencyTracker when a deadline hits. The deadline must be
canceled prior to going out of scope or else a DCHECK will fail.

BUG= 722064 ,  672962 ,  727162 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2887453002
Cr-Commit-Position: refs/heads/master@{#475601}

[modify] https://crrev.com/505078044cfca8e67070b4daed6e6157d7641774/cc/surfaces/BUILD.gn
[add] https://crrev.com/505078044cfca8e67070b4daed6e6157d7641774/cc/surfaces/surface_dependency_deadline.cc
[add] https://crrev.com/505078044cfca8e67070b4daed6e6157d7641774/cc/surfaces/surface_dependency_deadline.h
[modify] https://crrev.com/505078044cfca8e67070b4daed6e6157d7641774/cc/surfaces/surface_dependency_tracker.cc
[modify] https://crrev.com/505078044cfca8e67070b4daed6e6157d7641774/cc/surfaces/surface_dependency_tracker.h

Owner: fsam...@chromium.org
Status: Fixed (was: Available)
I think we've solved the display going away problem and the constantly observing BeginFrames problem now and so I'm marking this as FIXED.
Cc: toyoshim@chromium.org liberato@google.com
 Issue 727625  has been merged into this issue.
Labels: Merge-Request-60
Cc: shrike@chromium.org
 Issue 727162  has been merged into this issue.
Cc: simonhatch@chromium.org
 Issue 727622  has been merged into this issue.
Issue 726856 has been merged into this issue.
Cc: meh...@chromium.org
Labels: -Pri-3 M-60 ReleaseBlock-Stable OS-Mac Pri-1
Status: Assigned (was: Fixed)
Reopening because c#12 in  Issue 727162  (duplicate) is that the landed cl didn't fix the problem.
Cc: samans@chromium.org
Cc: perezju@chromium.org benhenry@chromium.org amineer@chromium.org
+benhenry, +amineer

This was marked as duplicate of issue 726856, probably the largest release blocking regression we see in M60 before branch point on Android.
Project Member

Comment 17 by sheriffbot@chromium.org, May 31 2017

Labels: -Merge-Request-60 Hotlist-Merge-Approved Merge-Approved-60
Your change meets the bar and is auto-approved for M60. Please go ahead and merge the CL to branch 3112 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
What's the plan to address the regression? Are we planning to justify this with SHC?
Looks like the graphs all recovered, though: https://chromeperf.appspot.com/group_report?bug_id=726856 Are we shipping this feature in M60?
Project Member

Comment 20 by bugdroid1@chromium.org, May 31 2017

Labels: -merge-approved-60 merge-merged-3112
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b13490405b5fffdda9d4ff79b3d74695335a11e9

commit b13490405b5fffdda9d4ff79b3d74695335a11e9
Author: Fady Samuel <fsamuel@chromium.org>
Date: Wed May 31 20:18:19 2017

SurfaceDependencyTracker: Only observe BeginFrames if a deadline is needed

Always observing deadlines could potentially prevent the CPU from idling because
that requires a timer to always fire. This CL only observes BeginFrames if there are
unresolved dependencies.

A new object type, SurfaceDependencyDeadline is introduced that
observes BeginFrames within its scope and reports back to
SurfaceDependencyTracker when a deadline hits. The deadline must be
canceled prior to going out of scope or else a DCHECK will fail.

BUG= 722064 ,  672962 ,  727162 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2887453002
Cr-Original-Commit-Position: refs/heads/master@{#475601}
Review-Url: https://codereview.chromium.org/2917743002 .
Cr-Commit-Position: refs/branch-heads/3112@{#63}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}

[modify] https://crrev.com/b13490405b5fffdda9d4ff79b3d74695335a11e9/cc/surfaces/BUILD.gn
[add] https://crrev.com/b13490405b5fffdda9d4ff79b3d74695335a11e9/cc/surfaces/surface_dependency_deadline.cc
[add] https://crrev.com/b13490405b5fffdda9d4ff79b3d74695335a11e9/cc/surfaces/surface_dependency_deadline.h
[modify] https://crrev.com/b13490405b5fffdda9d4ff79b3d74695335a11e9/cc/surfaces/surface_dependency_tracker.cc
[modify] https://crrev.com/b13490405b5fffdda9d4ff79b3d74695335a11e9/cc/surfaces/surface_dependency_tracker.h

Status: Fixed (was: Assigned)
I've merged this CL. I'm marking as FIXED now.
 Issue 727763  has been merged into this issue.
 Issue 727760  has been merged into this issue.
 Issue 727749  has been merged into this issue.
 Issue 727745  has been merged into this issue.
 Issue 727623  has been merged into this issue.
Cc: klausw@chromium.org
 Issue 727496  has been merged into this issue.
Blocking: -601863
Components: -Internals>MUS Internals>Services>WindowService

Sign in to add a comment