WebVR: improve motion-to-app-to-photon latency |
|||||
Issue descriptionCurrently, WebVR latency from pose to JS rendering to visibility on screen is too high, reaching >90ms even for simple scenes. This has multiple contributing factors: - pose is polled and provided to the mojo GetVSync callback when the Javascript thread isn't ready yet to handle it, leading to a stale pose by the time the rAF callback starts. - submitted frames are copied from Mailbox to Surface, the Surface/SurfaceTexture has internal buffering. Having an extra frame in this buffer causes a frame of extra latency. - fast submissions to GVR lead to buffer stuffing, GVR maintains 3 buffers total of which one is typically kept locked by GVR for reprojection. Submitted buffers are shown in strict FIFO order, an extra buffer in this queue leads to a frame of extra latency. - suboptimal timing for GVR submissions can cause blocking in frame acquire/submit, and/or up to one frame delay before the submitted frame can be shown. Goal for this tracker bug is to improve the rendering scheduling to avoid overstuffing buffers in this pipeline and thereby reducing overall latency.
,
May 23 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7b6d11d65c59a5e13a62942227b5caf16c70993a commit 7b6d11d65c59a5e13a62942227b5caf16c70993a Author: klausw <klausw@chromium.org> Date: Tue May 23 21:12:04 2017 WebVR: Defer GetVSync calls until the current frame is submitted. In order to help the VR device with scheduling, never request a new VSync until the current frame is either submitted or abandoned. If vrDisplay.rAF is called earlier, defer the GetVSync until vrDisplay.submitFrame is called. If the rAF callback exits without submitting a frame, call it at that time. This helps ensure that the VR device knows how long the rendering portion of the rAF callback takes, while making sure not to expect a frame that won't arrive because the client failed to submit one. BUG= 723962 Review-Url: https://codereview.chromium.org/2888313002 Cr-Commit-Position: refs/heads/master@{#474053} [add] https://crrev.com/7b6d11d65c59a5e13a62942227b5caf16c70993a/third_party/WebKit/LayoutTests/vr/requestAnimationFrame_handoff.html [add] https://crrev.com/7b6d11d65c59a5e13a62942227b5caf16c70993a/third_party/WebKit/LayoutTests/vr/requestAnimationFrame_submitFrame_combinations.html [modify] https://crrev.com/7b6d11d65c59a5e13a62942227b5caf16c70993a/third_party/WebKit/LayoutTests/vr/resources/mock-vr-service.js [modify] https://crrev.com/7b6d11d65c59a5e13a62942227b5caf16c70993a/third_party/WebKit/Source/modules/vr/VRDisplay.cpp [modify] https://crrev.com/7b6d11d65c59a5e13a62942227b5caf16c70993a/third_party/WebKit/Source/modules/vr/VRDisplay.h [modify] https://crrev.com/7b6d11d65c59a5e13a62942227b5caf16c70993a/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.json5
,
May 23 2017
,
May 24 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4493e8ab56406db9d3eb2a640662e0e95b383b4a commit 4493e8ab56406db9d3eb2a640662e0e95b383b4a Author: klausw <klausw@chromium.org> Date: Wed May 24 03:25:45 2017 WebVR unstuffing: delay "rendered" notification In order to prevent queue stuffing from overeager frame creation, ensure that we never have more than one frame being rendered while the next frame is being prepared in Javascript. The rendering time should include GVR overhead to avoid overcommitting rendering resources, so this change moves the "rendering done, ok to submit the next frame" notification past GVR submit. BUG= 723962 Review-Url: https://codereview.chromium.org/2897583002 Cr-Commit-Position: refs/heads/master@{#474147} [modify] https://crrev.com/4493e8ab56406db9d3eb2a640662e0e95b383b4a/chrome/browser/android/vr_shell/vr_shell_gl.cc
,
May 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0d764046b1e7ea6eb145e2aa39a88a6d0ac3e714 commit 0d764046b1e7ea6eb145e2aa39a88a6d0ac3e714 Author: Klaus Weidner <klausw@chromium.org> Date: Thu May 25 00:44:59 2017 WebVR: force vsync-aligned timing Currently, WebVR's vrDisplay.rAF gets run at 60fps on Android if the app can keep up, or as fast as possible if it cannot. Rendering at odd rates such as 50fps means that the animation loop will oscillate out of phase with vsync, and this causes jerky animation. Instead, try sending vrDisplay.rAF only at vsync. This means that applications that don't hit 60fps will be throttled to 30/20/15/12fps automatically. BUG= 723962 Change-Id: I524950a318fcedce7f33999efd40dccadc6bb41b Reviewed-on: https://chromium-review.googlesource.com/513662 Reviewed-by: Brandon Jones <bajones@chromium.org> Reviewed-by: Michael Thiessen <mthiesse@chromium.org> Commit-Queue: Klaus Weidner <klausw@chromium.org> Cr-Commit-Position: refs/heads/master@{#474499} [modify] https://crrev.com/0d764046b1e7ea6eb145e2aa39a88a6d0ac3e714/chrome/browser/android/vr_shell/vr_shell_gl.cc
,
May 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0d1a6048d093aeefb6eec350fcef6352326f5029 commit 0d1a6048d093aeefb6eec350fcef6352326f5029 Author: klausw <klausw@chromium.org> Date: Thu May 25 04:33:01 2017 Add SlidingAverage to FPSMeter, use for WebVR prediction time Refactor FPSMeter to extract the "sliding window sum" code into a separate class, use it in FPSMeter, and separately use it to implement a SlidingAverage class. This revealed a pre-existing bug where current_index_ was not being initialized, leading to wrong FPS calculations. Use SlidingAverage to calculate WebVR Javascript and rendering times, and use those to calculate the prediction time offset for GVR poses instead of hardcoding 50ms for this. BUG= 723962 Review-Url: https://codereview.chromium.org/2901213002 Cr-Commit-Position: refs/heads/master@{#474549} [modify] https://crrev.com/0d1a6048d093aeefb6eec350fcef6352326f5029/chrome/browser/android/vr_shell/fps_meter.cc [modify] https://crrev.com/0d1a6048d093aeefb6eec350fcef6352326f5029/chrome/browser/android/vr_shell/fps_meter.h [modify] https://crrev.com/0d1a6048d093aeefb6eec350fcef6352326f5029/chrome/browser/android/vr_shell/fps_meter_unittest.cc [modify] https://crrev.com/0d1a6048d093aeefb6eec350fcef6352326f5029/chrome/browser/android/vr_shell/vr_shell_gl.cc [modify] https://crrev.com/0d1a6048d093aeefb6eec350fcef6352326f5029/chrome/browser/android/vr_shell/vr_shell_gl.h [modify] https://crrev.com/0d1a6048d093aeefb6eec350fcef6352326f5029/device/vr/android/gvr/gvr_delegate.cc [modify] https://crrev.com/0d1a6048d093aeefb6eec350fcef6352326f5029/device/vr/android/gvr/gvr_delegate.h
,
May 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d9e6b495633f4f1382309dff618aa41af04413ee commit d9e6b495633f4f1382309dff618aa41af04413ee Author: Klaus Weidner <klausw@chromium.org> Date: Thu May 25 06:24:17 2017 WebVR: replace glFinish with a GLFenceEGL for async submission Replace the load-bearing glFinish with a GLFenceEGL object. Intent was to avoid blocking in GL calls in time-critical sections. In WebVR surfaceless rendering mode, poll for the fence to complete. This gives other code a chance to run while this is happening, specifically it helps ensure that WebVR's VSync calls get sent on time. In other modes (non-WebVR, or WebVR with normal surface rendering), schedule the submit step immediately, after yielding the event loop to process anything that may have been scheduled in the meantime. BUG= 723962 Change-Id: I317792a730de8c14ee128818ee8710764b227efb Reviewed-on: https://chromium-review.googlesource.com/513622 Reviewed-by: Michael Thiessen <mthiesse@chromium.org> Reviewed-by: David Dorwin <ddorwin@chromium.org> Commit-Queue: Klaus Weidner <klausw@chromium.org> Cr-Commit-Position: refs/heads/master@{#474583} [modify] https://crrev.com/d9e6b495633f4f1382309dff618aa41af04413ee/chrome/browser/android/vr_shell/vr_shell_gl.cc [modify] https://crrev.com/d9e6b495633f4f1382309dff618aa41af04413ee/chrome/browser/android/vr_shell/vr_shell_gl.h
,
May 31 2017
Closing since the currently planned changes for this issue have landed. The GL context priority change from issue 725684 had to be rolled back due to conflicts with GVR's own prioritization, this will need to wait for a larger refactor to support low-priority WebGL contexts or similar. The next focus items for M61 will be improving pipeline efficiency by removing extra copies and related buffering. Those should also help reduce latency but will be tracked separately.
,
May 31 2017
,
Jul 4
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by bugdroid1@chromium.org
, May 22 2017