1140723 - Enable vsync compositor on Windows

Status: RESOLVED FIXED

(Core :: Graphics, defect, P2)

Description

[Mason Chang [Inactive] [:mchang]]

+++ This bug was initially created as a clone of Bug #1137905 +++

Turn on the vsync compositor on Windows 7+ platforms.

Comment 1

[Mason Chang [Inactive] [:mchang]]

Talos numbers:

Base off commit bc6aeea72290 - https://treeherder.mozilla.org/#/jobs?repo=try&revision=fb39553b0473
Windows Vsync Compositor - https://treeherder.mozilla.org/#/jobs?repo=try&revision=768730b3ae1c

Compare talos - http://compare-talos.mattn.ca/dev/?oldBranch=Try&oldRevs=fb39553b0473&newBranch=Try&newRev=768730b3ae1c&submit=true

Comment 2

[Mason Chang [Inactive] [:mchang]]

Attachment: Enable the vsync compositor on Windows

Comment 3

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Any reason why "gfx.vsync.refreshdriver" will be left as "false" on Windows and all other platforms?

Comment 4

[Mason Chang [Inactive] [:mchang]]

(In reply to Virtual_ManPL [:Virtual] from comment #3)
> Any reason why "gfx.vsync.refreshdriver" will be left as "false" on Windows
> and all other platforms?

I want to enable one preference at a time to make sure everything is stable. We're having known problems with enabling the refresh driver on b2g as well.

Comment 5

[Mason Chang [Inactive] [:mchang]]

Took a look at some of the talos regressions. From the sessionrestore_no_auto_restore, the test throttles the refresh driver compositor and ticks often from a RecvDidComposite from the compositor. The compositor gets scheduled right away on the compositor loop due to a delay, which kicks off the next refresh driver tick since the Compositor returns with a SendDidComposite sooner, whereas with silk, we wait until the next vsync. 

master
http://people.mozilla.org/~bgirard/cleopatra/?zippedProfile=http://mozilla-releng-blobs.s3.amazonaws.com/blobs/Try-Non-PGO/sha512/2142ccda3f23bd663772f5fe191283c2b085a4f35915989b3714c975968962239f29610cb97ae9c3d1f11b60c581c88103fcd8a64d8df96eefb96e4fc7dc21b1&pathInZip=profile_sessionrestore_no_auto_restore/startup/cycle_2.sps#report=5cd94374f3f3f1788c582efc5d7e21d2b79e1d0e

silk
http://people.mozilla.org/~bgirard/cleopatra/?zippedProfile=http://mozilla-releng-blobs.s3.amazonaws.com/blobs/Try-Non-PGO/sha512/5dbc14b050830c18dd9edb2c878861b6e1ae3fd48f25a78d82a1e5afdb3c5a112317162ab70728f9c2038073d45ee57b7809b31c54ed0aa0d9925230632bf39b&pathInZip=profile_sessionrestore_no_auto_restore/startup/cycle_5.sps#report=e9746ed27fc8c00b671a115255e436447a2b5948

Comment 6

[Mason Chang [Inactive] [:mchang]]

Explanation fail. The test throttles the refresh driver so that the compositor doesn't get ahead. After the compositor finishes compositing, it sends a message back to the refresh driver so that the refresh driver can tick again. This is the DidComposite message. 

With the software timer compositor, we ticked the refresh driver at an odd time but after 1 composite interval. When the compositor gets the layer transaction, it thinks it it's late since it didn't Composite for a while, so it composites right away. After the composite, it sends a DidComposite message, which ticks the refresh driver again. With silk, we have to wait until the next vsync to composite, which then sends the DidComposite message.

Comment 7

[Avi Halachmi (:avih)]

(In reply to Mason Chang [:mchang] from comment #5)
> ... whereas with silk, we wait until the next vsync. 

Do the numbers reflect this with regression < 17ms ? (not later than the next vsync).

If this only due to the test setup and unlikely to happen under normal/heavy scenarios to users, then it's probably OK IMO, but if this happens to represent a scenario where users could notice the delay in rendering, then it might need some consideration.

Can you assess this?

Comment 8

[Mason Chang [Inactive] [:mchang]]

(In reply to Avi Halachmi (:avih) from comment #7)
> (In reply to Mason Chang [:mchang] from comment #5)
> > ... whereas with silk, we wait until the next vsync. 
> 
> Do the numbers reflect this with regression < 17ms ? (not later than the
> next vsync).
> 
> If this only due to the test setup and unlikely to happen under normal/heavy
> scenarios to users, then it's probably OK IMO, but if this happens to
> represent a scenario where users could notice the delay in rendering, then
> it might need some consideration.
> 
> Can you assess this?

In this case, the regression is ~15ms from a runtime of ~730ms to 745 ms, which is less than one vsync. When we are throttling the compositor, it means that the compositor can't keep up with the refresh driver. With silk, by design, we only composite on vsyncs, whereas before we would try to keep up ASAP before. The delay in rendering should be at most one frame, which is ok IMHO.

Comment 9

[Mason Chang [Inactive] [:mchang]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/d3380179efc1

Comment 10

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/d3380179efc1