1344379 - How accurate/bad are the vsync ticks

Status: NEW

(Core :: Graphics, enhancement, P3)

Description

[Milan Sreckovic [:milan] (needinfo for best results)]

Looking at the telemetry for REFRESH_DRIVER_TICKS (and, on the side looking at FX_REFRESH_DRIVER_CONTENT_FRAME_DELAY_MS and FX_REFRESH_DRIVER_CHROME_FRAME_DELAY_MS), it appears that we have a very large number of delayed ticks.   According to the first one, about 5% are more than 8ms (half the frame budget) late, and 1.6% are more than full frame budget (16ms) late.  That means that we miss a frame once per second even with infinitely fast processing.

We need to confirm these numbers, and if they're correct, figure out if we can improve this, and how (perhaps on a subset of systems, given the issues we've seen on some Windows machines.)

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

Not sure if it affects these probes, but keep in mind requestAnimationFrame() means we must run arbitrary JS during the refresh driver.

Comment 2

[Milan Sreckovic [:milan] (needinfo for best results)]

Indeed.  What I'm interested in is whether the vsync ticks, which are in a separate thread, are arriving on schedule.  Not being able to process them in time is a separate issue, once we confirm that the clock itself is working properly.  Well, we know it isn't, but we'd like to understand how close we are.

Comment 3

[Mason Chang [Inactive] [:mchang]]

(In reply to Milan Sreckovic [:milan] from comment #2)
> Indeed.  What I'm interested in is whether the vsync ticks, which are in a
> separate thread, are arriving on schedule.  Not being able to process them
> in time is a separate issue, once we confirm that the clock itself is
> working properly.  Well, we know it isn't, but we'd like to understand how
> close we are.

The current telemetry probes measure how long it takes to process a vblank compared to the time when vsync "should" have happened. E.g., if the main thread is busy due to whatever reason, we're going to have a long delay with those probes. There isn't really an "arriving on schedule" here since the vsync thread just sends the message over and we don't record the probe until the main thread can process it. 

Did you want a separate probe of "when vblank woke up versus when vblank actually happened? We don't have a probe for that yet. In terms of what happens we have:

1) Actual physical hardware vblank happens.
2) When the vsync thread wakes up - http://searchfox.org/mozilla-central/source/gfx/thebes/gfxWindowsPlatform.cpp#1835 - not really under our control
3) Vsync posts a message to the main thread saying vblank happened with the timestamp of (1)
4) The main thread / refresh driver processes (3).

The current probe we have right now measures the latency between (3) and (4). We know we have some delay between (1) and (2). The time for 2-3 should be minimal. Does that answer your question?

Comment 4

[Milan Sreckovic [:milan] (needinfo for best results)]

Good explanation, thanks.

If (3 - 2) is minimal and constant, then we'd want to see the distribution of (2 - 1), or (3 - 1).

When you say the current probe measures (4 - 3) - which of the three probes is that?  REFRESH_DRIVER_TICKS, FX_REFRESH_DRIVER_CONTENT_FRAME_DELAY_MS or FX_REFRESH_DRIVER_CHROME_FRAME_DELAY_MS?  Or combination?

Comment 5

[Mason Chang [Inactive] [:mchang]]

We can add a probe for (2-1 or 3-1), if you'd like. I should add clarification, the current probe measures between (1-4) since we're measuring the time since the vsync was supposed to happen. I do know that 3-1 can be a lot of noise, especially under load. Another thing is that DwmGetCompositionTime can lie to you of when vsync actually happened. I've seen 10ms long delays until waking up :(. Maybe a better probe would be how long it takes to wake up via DwmFlush if you're interested.

In terms of the probes:
- FX_REFRESH_DRIVER_CHROME_FRAME_DELAY_MS - This is the latency between (1-4) on the parent process only.
- FX_REFRESH_DRIVER_CONTENT_FRAME_DELAY_MS - this is the latency between refresh driver ticks rather than between vsync. 
- REFRESH_DRIVER_TICKS - This is how long it takes on the main thread to process a frame.

The content one is different than the parent one because with APZ, scrolling smoothness would depend on accurate and smooth vsync timestamps. We expected content to take longer to render with APZ due to a larger display port, so we just wanted to measure how busy the content process is before we'd start painting again.

Comment 6

[Thomas Andre]

Have you guys thought about maybe using D3DKMTWaitForVerticalBlankEvent() ? Seems like chrome already has started using this if you flip the D3D vsync flag.

Comment 7

[Mason Chang [Inactive] [:mchang]]

(In reply to Thomas Andre from comment #6)
> Have you guys thought about maybe using D3DKMTWaitForVerticalBlankEvent() ?
> Seems like chrome already has started using this if you flip the D3D vsync
> flag.

Yes. We can't do this because WaitForVerticalBlank isn't supported if you use it on a different thread than where you initialize your D3D devices. We tried this and it basically locked up Firefox :(

Comment 8

[David Anderson [:dvander] - inactive, e-mail if emergency]

We might be able to try it in the GPU process, and drive vsync from there.

Comment 9

[Thomas Andre]

Speaking of DWM it seems that Microsoft has changed something in the insider builds over 16215 and broken HW vsync.

I think I remember them saying they will maybe add per monitor vsync in redstone 3.