vsync

[Predut, Marius]

I done a benchmark test(aquarium web gl application) with vsync enabled and without(--disable-gpu-vsync) and the results was not how I expected,
With vsync enabled(default) I got around 40 fps, without vsync(disable) 60 fps.

Normally I expected vsync to not affect values so much for less than 60 fps. Only in case greater than 60 fps I expect big difference.

I see in the source code that when vsync is enable the interval time is set to 1.

Is this correct or not , other thought?


marius

[Nicolas Capens]

Did you test this on Chrome Canary? On Windows we've recently disabled vsync at the OpenGL level: https://codereview.chromium.org/299443020/, which should effectively have the same effect as --disable-gpu-vsync. Thus Chrome solely relies on the compositor for refresh synchronization now.

[Predut, Marius]

My test was on linux ubuntu (linux kernel 3.12 ), chromium svn rev. 272967(2-3 days before today)

[Brian C. Anderson]

Can you attach a trace of your use case? There are a few things that could be going on here and a trace would help narrow down the cause:

1. If we are double buffered, hardware vsync affects the timing of when we can start drawing to the back buffer. If a swap request *just* misses the vsync, it has to wait until the next vsync to swap and start drawing the next frame. When double buffered, GPU hardware bound, and vsync is enabled, we should drop to 30fps from 60fps assuming a constant GPU workload. The fact that you are seeing 40fps with vsync enabled indicates either:
1. We are not GPU hardware bound and the bottleneck is elsewhere.
2. The GPU workload isn't constant, sometimes taking more than a vsync and other times less.
3. We are triple buffered. If we were triple buffered though, I would expect us to operate much closer to the vsync disabled rate.
2. If we are not GPU hardware bound, Chrome's GPU service is another likely bottleneck. Vsync enabled could be making Chrome's GPU service sleep more often than when vsync is disabled. This could be from backpressure from (1.2), but I've also seen drivers that just like to sleep more often with vsync enabled.
3. The Renderer is the bottleneck and has an uneven workload. With vsync enabled, we give the Renderer a whole vsync to produce a frame. With vsync disabled, it has essentially forever to produce a frame. We could give it more than a vsync with long deadlines, but we haven't implemented that yet. Long deadlines would give us some immunity against uneven Renderer workloads.

[Nicolas Capens]

On Thu, May 29, 2014 at 2:24 PM, Brian C. Anderson <brian...@google.com> wrote:

Can you attach a trace of your use case? There are a few things that could be going on here and a trace would help narrow down the cause:

1. If we are double buffered, hardware vsync affects the timing of when we can start drawing to the back buffer. If a swap request *just* misses the vsync, it has to wait until the next vsync to swap and start drawing the next frame. When double buffered, GPU hardware bound, and vsync is enabled, we should drop to 30fps from 60fps assuming a constant GPU workload. The fact that you are seeing 40fps with vsync enabled indicates either:
1. We are not GPU hardware bound and the bottleneck is elsewhere.
2. The GPU workload isn't constant, sometimes taking more than a vsync and other times less.
3. We are triple buffered. If we were triple buffered though, I would expect us to operate much closer to the vsync disabled rate.

Thanks for laying it out like that. I think with ANGLE we were 'kindof' in situation (3) because we're using double buffering with an additional texture as the render target which we have to draw upside down into the back buffer because of the difference in DX and GL coordinate system. So it's almost triple buffering but the flip upside down could sometimes happen before a vsync and sometimes after.

I wonder if the same thing could be happening on Linux, except there's no flipping upside down but still a regular bitblt. In other words, windowed triple buffering could be implemented as two screen sized buffers that use pointer swapping and a third window sized buffer that uses a bitblt. That way if you issue a swap right before the vsync is may actually still end up after the vsync due to the bitblt time and the pointer swap has to wait for the next vsync.

[Predut, Marius]

 

Hi Guys.

Thanks for those clarifications.

I attached the json trace files with and without vsync.

My command used is:

vblank_mode=0 ./out/Debug/chrome  --no-sandbox --enable-impl-side-painting --use-gl=egl --show-fps-counter --disable-gpu-vsync

(vblank_mode=0 is used for mesa to disable vsync but it seems not affect result because his own chromium vsync management)

 

When I run my tests I used content_shell, but because I know to do "trace" only from UI( than "chrome://tracing/"),

now I was forced to use chrome(Is possible to trace only with content_shell? )

 

Other strange behavior on my side :

I made 2 tests with INTEL "zero copy stuff"(I am working on)

(chrome switches --enable-zero-copy, --ui-enable-zero-copy),

first test with an old chromium upstream version ( 2 weeks before, svn rev 263834) and

the second  with last chromium upstream version(3 days before, svn rev 272968) and

the result was the FPS was degraded(from 60 fps to 40 fps -vsync enabled for both situations) .

 

I see, on this period(last 2-3 weeks) was added updates(most relevant is gpu memory buffer part )that can impact it and generate this FPS regression or not?

Or maybe can something wrong on my side.

 

thanks

marius

[Brian C. Anderson]

On Fri, May 30, 2014 at 6:07 AM, Predut, Marius <marius...@intel.com> wrote:

 

Hi Guys.

Thanks for those clarifications.

I attached the json trace files with and without vsync.

The attached traces show single frames drawn very sparsely. Can you try capturing traces again?

 

My command used is:

vblank_mode=0 ./out/Debug/chrome  --no-sandbox --enable-impl-side-painting --use-gl=egl --show-fps-counter --disable-gpu-vsync

(vblank_mode=0 is used for mesa to disable vsync but it seems not affect result because his own chromium vsync management)

 

When I run my tests I used content_shell, but because I know to do "trace" only from UI( than "chrome://tracing/"),

now I was forced to use chrome(Is possible to trace only with content_shell? )

Does the following command line flags work:

--trace-startup --trace-startup-file=/tmp/foo.json  --trace-startup-duration=7

(Taken from http://dev.chromium.org/developers/how-tos/trace-event-profiling-tool/recording-tracing-runs)

[Predut, Marius]

"foo" json can be generated with google upstream svn Revision: 274314

"zero_copy" json file can be generated only if on top of google upstream was applied this patch:
https://codereview.chromium.org/288343004/


marius

[Brian C. Anderson]

From a quick look, it seems like we are Renderer main-thread limited:

• Can you see if the following patch helps you at all: https://codereview.chromium.org/222023010/
  
• Also, you might want to try the experimental command-line flag --enable-main-frame-before-activation
  

Some other folks (Including Matt from Intel's CrOS team) have complained separately about other WebGL slow downs that started showing up after a recent refactor. We found that the following two patches helped since they fix bugs in the original refactor. You might also want to give them a try:

• https://codereview.chromium.org/311263016/
  
• https://codereview.chromium.org/311353003/
  

[Predut, Marius]

Thanks for feedback, with the latest upstream code the FPS I got looks like I expected,

So the regression seems to be fixed.