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

Issue 693761 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Jun 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug

Blocked on:
issue 480361



Sign in to add a comment

--disable-gpu-vsync=gpu doesn't display renderer contents.

Project Member Reported by jbau...@chromium.org, Feb 17 2017

Issue description

Maybe the BeginFrame isn't being sent to the renderer in this case.

Also I'm not sure in what cases we'd want the renderer to be throttled but the browser to be unthrottled, or vice versa. I think it would make more sense for --disable-gpu-vsync=gpu to only disable the GL vsync, but leave frame throttling unchanged.
 

Comment 1 by kbr@chromium.org, Feb 18 2017

Blockedon: 480361

Comment 2 by jer...@duckware.com, Feb 18 2017

My results, under Windows, using Canary 58.0.3016.0:

  --disable-gpu-vsync  (a very fast frame rate; just started working; see  issue 480361 )
  --disable-gpu-vsync=gpu (a blank GUI that does not update)
  --disable-gpu-vsync=beginframe (works, vsynced; assumed back pressure from ANGLE)

The features that I need in a "disable-gpu-vsync" are:

(1) Chrome producing frames as fast as it can -- for performance testing.  This currently works (just fixed).

(2) Keep Chrome 100% the same, but turn off ONLY angle vsync (keep everything else in Chrome working as-is).  I can currently turn angle vsync off by utilizing another bug in Chrome, but a command line option is needed.

As (1) now works, the justification and reason why (2) is important is for testing in issue 460919.  Chrome has two vsync methods under Windows.  The first way is an internal vsync (timebase/interval + Windows compositor=AeroGlass).  The second way is an external vsync (Angle/DirectX vsync).  The first way was always broken in Chrome up until issue 422000 (due to a flat out wrong timebase/interval being used), which required Chrome to turn on the second way in order to vsync.  But during issue 422000, the first way was fixed and vsync's properly.  But the second way (ANGLE vsync) is still enabled.  Being able to turn off ONLY that second way is needed for testing -- to see if only the first vsync way under Windows is enough.
Cc: stanisc@chromium.org
ANGLE v-sync is turned on here:

https://cs.chromium.org/chromium/src/gpu/ipc/service/pass_through_image_transport_surface.cc?type=cs&l=152

 gl::GLContext::GetCurrent()->SetSwapInterval(1);

This translates to passing SyncInterval=1 to IDXGISwapChain::Present.
Actually swap interval is forced to be zero when --disable-gpu-vsync is present (with any value). That should turn off ANGLE VSYNC.

I don't see any issues with --disable-gpu-vsync=gpu on my worstation. It works roughly the same as --disable-gpu-vsync
Project Member

Comment 6 by sheriffbot@chromium.org, Jun 7 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 7 by enne@chromium.org, Jun 7 2018

I suspect sunnyps fixed this and this can be closed.
Owner: sunn...@chromium.org
Status: Assigned (was: Untriaged)
sunnyps@, could you close this bug if its already fixed?
Status: Fixed (was: Assigned)
This has been fixed. There are two flags now: --disable-gpu-vsync only disables vsync for swap chain present or sets SwapInterval(0) etc., and --disable-frame-rate-limit which disables vsync driving begin frames for both display and renderer compositors.

Sign in to add a comment