find attached chrome://gpu infos

Deleted: gpu.htm 104 KB

gpu.htm 104 KB View Download

Sunny, Brian: what guarantees do we provide about --disable-gpu-vsync working?

We try to keep it working since it's useful for quick and dirty performance testing, but not with a high priority.

There's a related  issue 480361 .

Is vsync only disabled after resizing the window like in  issue 480361 ?

Able to reproduce the issue on reported version 62.0.3202.94 and latest build 64.0.3275.0 using Windows 10, Ubuntu 14.04 and Mac 10.12.6. As the issue is seen from M-50 (50.0.2641.0) considering it as Non-Regression and marking it as Untriaged. Please find the attached reference documents

Deleted: chrome___gpu_787485.pdf 130 KB

chrome___gpu_787485.pdf 130 KB Download

Adding screenshot from 62.0.3202.94, 64.0.3275.0 and 50.0.2641.0

Deleted: 787485.docx 1023 KB

787485.docx 1023 KB Download

This did indeed break when we started using Direct Composition. Fix is under way.

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

commit 8680afd3a5b1cb26b0c7a43ab8cf739a59be812c
Author: Sunny Sachanandani <sunnyps@chromium.org>
Date: Thu Mar 08 02:06:19 2018

gpu: Make --disable-gpu-vsync work with direct composition

This broke because the direct composition path doesn't use swap interval
set by eglSwapInterval in ANGLE. Since we only care about disabling via
command line, it's ok to just handle that instead of SetSwapInterval.

This will still not work when we use a direct composition surface
instead of swap chain but that only happens when we use overlays. There
may be no way to make this case work since the swap chain is not
controlled by Chrome.

Tested with vsynctester.com on my home desktop.

R=kbr,piman
BUG= 480361 , 787485 

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
Change-Id: Ife5804b4e9bcede41bb29cd01e54e81f0d278b62
Reviewed-on: https://chromium-review.googlesource.com/954020
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Cr-Commit-Position: refs/heads/master@{#541687}
[modify] https://crrev.com/8680afd3a5b1cb26b0c7a43ab8cf739a59be812c/gpu/ipc/service/direct_composition_child_surface_win.cc
[modify] https://crrev.com/8680afd3a5b1cb26b0c7a43ab8cf739a59be812c/gpu/ipc/service/direct_composition_child_surface_win.h

Unable to reproduce this issue on reported version 62.0.3202.94, on build 62.0.3202.94 , on latest stable 65.0.3325.146 , on build without fix 66.0.3364.0 using steps given in comment#0. i.e; FPS is seen ranging from 30-50 on both build with fix and without fix.  Attaching screenshots for reference. 

Hence it will not be possible to verify the fix on build with fix i.e; 66.0.3366.0.

@Reporter: Please help in verifying the issue on latest canary from your side. You can download latest canary from https://www.chromium.org/getting-involved/dev-channel.

Thanks!

Deleted: Build with fix.png 90.1 KB

	Build with fix.png 90.1 KB View Download

Deleted: Build without fix.png 141 KB

	Build without fix.png 141 KB View Download

sorry for the late answer, the command line switch is ok since a previous
chrome updates. You can close.

FWIW there are two flags now: --disable-gpu-vsync disables vsync for Present or SwapBuffers (and enables tearing), and --disable-frame-rate-limit makes the compositor (display and renderer) go as fast as possible.