|
|
DescriptionD3D V-sync: prevent timestamp drift on a secondary monitor
I got back some preliminary UMA data from Canary experiment that
confirm the timestamp drift relative to the timing of v-sync signal
which makes BeginImplFrameLatency2 UMA to be all over the place with
a distribution that is spread evenly in the entire 0 - 16667 range.
This happens because D3D V-sync signal is generated based on v-blank
event for a display that contains contains the window (the current
display), but the timestamp is obtained from DWM which is based on
the most recent v-blank timing for the primary monitor. So if a
secondary monitor frequency is even slightly different that causes
v-sync / RAF timestamp drift that is clearly visible on some websites
like vsynctester.com.
One possible solution is to capture the timestamp when v-blank event
is received, but that seems to be a bit less smooth than the DWM
timestamp. So the compromise is to use DWM timing only when running on
a primary monitor; otherwise use the v-blank wake-up timestamp.
I've verified that this fixes BeginImplFrameLatency2 UMA distribution on
my setup where the secondary monitor refresh rate seems to differ from
the primary monitor by about 0.15 Hz.
BUG=467617, 680639
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Review-Url: https://codereview.chromium.org/2874833003
Cr-Commit-Position: refs/heads/master@{#472279}
Committed: https://chromium.googlesource.com/chromium/src/+/873b91f1c41220589c05e39a9424ffc99eab785a
Patch Set 1 #Patch Set 2 : Merged and fixed a typo in a comment. #
Messages
Total messages: 24 (20 generated)
Description was changed from ========== Use now() v-sync timestamp on a secondary display. BUG= ========== to ========== Use now() v-sync timestamp on a secondary display. BUG= CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel ==========
The CQ bit was checked by stanisc@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Description was changed from ========== Use now() v-sync timestamp on a secondary display. BUG= CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel ========== to ========== D3D V-sync: prevent timestamp drift on a secondary monitor BUG=467617 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel ==========
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: mac_optional_gpu_tests_rel on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_optional_gpu_...)
Description was changed from ========== D3D V-sync: prevent timestamp drift on a secondary monitor BUG=467617 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel ========== to ========== D3D V-sync: prevent timestamp drift on a secondary monitor I got back some preliminary UMA data from Canary experiment that confirm the timestamp drift relative to the timing of v-sync signal which makes BeginImplFrameLatency2 UMA to be all over the place with a distribution that is spread evenly in the entire 0 - 16667 range. This happens because D3D V-sync signal is generated based on v-blank event for a display that contains contains the window (the current display), but the timestamp is obtained from DWM which is based on the most recent v-blank timing for the primary monitor. So if a secondary monitor frequency is event slightly different that causes v-sync / RAF timestamp drift that is clearly visible on some websites like vsynctester.com. One possible solution is to capture the timestamp when v-blank event is received, but that seems to be a bit less smooth than the DWM timestamp. So the compromise is to use DWM timing only when running on a primary monitor otherwise use the v-blank wake-up timestamp. I've verified that this fixes BeginImplFrameLatency2 UMA distribution on my setup where the secondary monitor refresh rate seems to differ from the primary monitor by about 0.15 Hz. BUG=467617,680639 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel ==========
Description was changed from ========== D3D V-sync: prevent timestamp drift on a secondary monitor I got back some preliminary UMA data from Canary experiment that confirm the timestamp drift relative to the timing of v-sync signal which makes BeginImplFrameLatency2 UMA to be all over the place with a distribution that is spread evenly in the entire 0 - 16667 range. This happens because D3D V-sync signal is generated based on v-blank event for a display that contains contains the window (the current display), but the timestamp is obtained from DWM which is based on the most recent v-blank timing for the primary monitor. So if a secondary monitor frequency is event slightly different that causes v-sync / RAF timestamp drift that is clearly visible on some websites like vsynctester.com. One possible solution is to capture the timestamp when v-blank event is received, but that seems to be a bit less smooth than the DWM timestamp. So the compromise is to use DWM timing only when running on a primary monitor otherwise use the v-blank wake-up timestamp. I've verified that this fixes BeginImplFrameLatency2 UMA distribution on my setup where the secondary monitor refresh rate seems to differ from the primary monitor by about 0.15 Hz. BUG=467617,680639 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel ========== to ========== D3D V-sync: prevent timestamp drift on a secondary monitor I got back some preliminary UMA data from Canary experiment that confirm the timestamp drift relative to the timing of v-sync signal which makes BeginImplFrameLatency2 UMA to be all over the place with a distribution that is spread evenly in the entire 0 - 16667 range. This happens because D3D V-sync signal is generated based on v-blank event for a display that contains contains the window (the current display), but the timestamp is obtained from DWM which is based on the most recent v-blank timing for the primary monitor. So if a secondary monitor frequency is event slightly different that causes v-sync / RAF timestamp drift that is clearly visible on some websites like vsynctester.com. One possible solution is to capture the timestamp when v-blank event is received, but that seems to be a bit less smooth than the DWM timestamp. So the compromise is to use DWM timing only when running on a primary monitor otherwise use the v-blank wake-up timestamp. I've verified that this fixes BeginImplFrameLatency2 UMA distribution on my setup where the secondary monitor refresh rate seems to differ from the primary monitor by about 0.15 Hz. BUG=467617,680639 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel ==========
stanisc@chromium.org changed reviewers: + jbauman@chromium.org
PTAL!
Description was changed from ========== D3D V-sync: prevent timestamp drift on a secondary monitor I got back some preliminary UMA data from Canary experiment that confirm the timestamp drift relative to the timing of v-sync signal which makes BeginImplFrameLatency2 UMA to be all over the place with a distribution that is spread evenly in the entire 0 - 16667 range. This happens because D3D V-sync signal is generated based on v-blank event for a display that contains contains the window (the current display), but the timestamp is obtained from DWM which is based on the most recent v-blank timing for the primary monitor. So if a secondary monitor frequency is event slightly different that causes v-sync / RAF timestamp drift that is clearly visible on some websites like vsynctester.com. One possible solution is to capture the timestamp when v-blank event is received, but that seems to be a bit less smooth than the DWM timestamp. So the compromise is to use DWM timing only when running on a primary monitor otherwise use the v-blank wake-up timestamp. I've verified that this fixes BeginImplFrameLatency2 UMA distribution on my setup where the secondary monitor refresh rate seems to differ from the primary monitor by about 0.15 Hz. BUG=467617,680639 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel ========== to ========== D3D V-sync: prevent timestamp drift on a secondary monitor I got back some preliminary UMA data from Canary experiment that confirm the timestamp drift relative to the timing of v-sync signal which makes BeginImplFrameLatency2 UMA to be all over the place with a distribution that is spread evenly in the entire 0 - 16667 range. This happens because D3D V-sync signal is generated based on v-blank event for a display that contains contains the window (the current display), but the timestamp is obtained from DWM which is based on the most recent v-blank timing for the primary monitor. So if a secondary monitor frequency is even slightly different that causes v-sync / RAF timestamp drift that is clearly visible on some websites like vsynctester.com. One possible solution is to capture the timestamp when v-blank event is received, but that seems to be a bit less smooth than the DWM timestamp. So the compromise is to use DWM timing only when running on a primary monitor otherwise use the v-blank wake-up timestamp. I've verified that this fixes BeginImplFrameLatency2 UMA distribution on my setup where the secondary monitor refresh rate seems to differ from the primary monitor by about 0.15 Hz. BUG=467617,680639 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel ==========
lgtm
Patchset #2 (id:20001) has been deleted
The CQ bit was checked by stanisc@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Description was changed from ========== D3D V-sync: prevent timestamp drift on a secondary monitor I got back some preliminary UMA data from Canary experiment that confirm the timestamp drift relative to the timing of v-sync signal which makes BeginImplFrameLatency2 UMA to be all over the place with a distribution that is spread evenly in the entire 0 - 16667 range. This happens because D3D V-sync signal is generated based on v-blank event for a display that contains contains the window (the current display), but the timestamp is obtained from DWM which is based on the most recent v-blank timing for the primary monitor. So if a secondary monitor frequency is even slightly different that causes v-sync / RAF timestamp drift that is clearly visible on some websites like vsynctester.com. One possible solution is to capture the timestamp when v-blank event is received, but that seems to be a bit less smooth than the DWM timestamp. So the compromise is to use DWM timing only when running on a primary monitor otherwise use the v-blank wake-up timestamp. I've verified that this fixes BeginImplFrameLatency2 UMA distribution on my setup where the secondary monitor refresh rate seems to differ from the primary monitor by about 0.15 Hz. BUG=467617,680639 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel ========== to ========== D3D V-sync: prevent timestamp drift on a secondary monitor I got back some preliminary UMA data from Canary experiment that confirm the timestamp drift relative to the timing of v-sync signal which makes BeginImplFrameLatency2 UMA to be all over the place with a distribution that is spread evenly in the entire 0 - 16667 range. This happens because D3D V-sync signal is generated based on v-blank event for a display that contains contains the window (the current display), but the timestamp is obtained from DWM which is based on the most recent v-blank timing for the primary monitor. So if a secondary monitor frequency is even slightly different that causes v-sync / RAF timestamp drift that is clearly visible on some websites like vsynctester.com. One possible solution is to capture the timestamp when v-blank event is received, but that seems to be a bit less smooth than the DWM timestamp. So the compromise is to use DWM timing only when running on a primary monitor; otherwise use the v-blank wake-up timestamp. I've verified that this fixes BeginImplFrameLatency2 UMA distribution on my setup where the secondary monitor refresh rate seems to differ from the primary monitor by about 0.15 Hz. BUG=467617,680639 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel ==========
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
The CQ bit was checked by stanisc@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from jbauman@chromium.org Link to the patchset: https://codereview.chromium.org/2874833003/#ps40001 (title: "Merged and fixed a typo in a comment.")
CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch. Bot data: {"patchset_id": 40001, "attempt_start_ts": 1494982549546710, "parent_rev": "5e6a740eee14d5d62c00723774051409fc9931df", "commit_rev": "873b91f1c41220589c05e39a9424ffc99eab785a"}
Message was sent while issue was closed.
Description was changed from ========== D3D V-sync: prevent timestamp drift on a secondary monitor I got back some preliminary UMA data from Canary experiment that confirm the timestamp drift relative to the timing of v-sync signal which makes BeginImplFrameLatency2 UMA to be all over the place with a distribution that is spread evenly in the entire 0 - 16667 range. This happens because D3D V-sync signal is generated based on v-blank event for a display that contains contains the window (the current display), but the timestamp is obtained from DWM which is based on the most recent v-blank timing for the primary monitor. So if a secondary monitor frequency is even slightly different that causes v-sync / RAF timestamp drift that is clearly visible on some websites like vsynctester.com. One possible solution is to capture the timestamp when v-blank event is received, but that seems to be a bit less smooth than the DWM timestamp. So the compromise is to use DWM timing only when running on a primary monitor; otherwise use the v-blank wake-up timestamp. I've verified that this fixes BeginImplFrameLatency2 UMA distribution on my setup where the secondary monitor refresh rate seems to differ from the primary monitor by about 0.15 Hz. BUG=467617,680639 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel ========== to ========== D3D V-sync: prevent timestamp drift on a secondary monitor I got back some preliminary UMA data from Canary experiment that confirm the timestamp drift relative to the timing of v-sync signal which makes BeginImplFrameLatency2 UMA to be all over the place with a distribution that is spread evenly in the entire 0 - 16667 range. This happens because D3D V-sync signal is generated based on v-blank event for a display that contains contains the window (the current display), but the timestamp is obtained from DWM which is based on the most recent v-blank timing for the primary monitor. So if a secondary monitor frequency is even slightly different that causes v-sync / RAF timestamp drift that is clearly visible on some websites like vsynctester.com. One possible solution is to capture the timestamp when v-blank event is received, but that seems to be a bit less smooth than the DWM timestamp. So the compromise is to use DWM timing only when running on a primary monitor; otherwise use the v-blank wake-up timestamp. I've verified that this fixes BeginImplFrameLatency2 UMA distribution on my setup where the secondary monitor refresh rate seems to differ from the primary monitor by about 0.15 Hz. BUG=467617,680639 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel Review-Url: https://codereview.chromium.org/2874833003 Cr-Commit-Position: refs/heads/master@{#472279} Committed: https://chromium.googlesource.com/chromium/src/+/873b91f1c41220589c05e39a9424... ==========
Message was sent while issue was closed.
Committed patchset #2 (id:40001) as https://chromium.googlesource.com/chromium/src/+/873b91f1c41220589c05e39a9424... |