[Wayland-bugs] [Bug 106736] With Vsync disabled, Weston almost halves *visible* frame update rate, compared to X desktop

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106736

--- Comment #14 from Pekka Paalanen <ppaalanen at gmail.com> ---
(In reply to Eero Tamminen from comment #13)
> (In reply to Pekka Paalanen from comment #11)

...

> * If compositor on some platform skips screen updates, that gives unfair
> performance advantage (number) on that platform

...

> [1] such as compositing, which is 100% memory bandwidth bound and for which
> one can actually calculate the expected performance.

I understand all the above (including the ones I cut out in the quote) as just
more reasons to run benchmarks with vsync on. If one does not actually display
every frame, like you said, the compositor overhead will be a random factor
since it will be processing some frames but not all.

Another way is to increase the benchmark complexity until it just starts
missing vblanks.

But then again the compositor's design will play a part: a compositor could in
its repaint check whether a client buffer is ready, and if it is not, postpone
it to the next refresh. This is actually something I would like in Weston, so
that applications could not delay screen updates arbitrarily and make e.g.
pointer cursor motion choppy.

So really, maybe benchmarks should be using fences and reading their completion
timestamps to figure out how long it took to execute a GPU task. Since most
GPUs still don't really pre-empt, that should be quite robust against
compositor overheads.


> > Games need to be designed to have vsync on.
> 
> Problem is that games have variable frame rate and people like to crank
> settings as high as possible.  They also have higher than 60 FPS monitor.
> 
> Solutions for avoiding getting only half the FPS with Vsync are either using
> FreeSync/Gsync and monitor capable of that, or disabling Vsync.
> 
> Btw. How well Xwayland & Wayland compositors work with FreeSync (and Gsync)?
> 
> (FreeSync has been part of DP & HDMI specs quite a while now.)

Variable refresh rate is an aid to let keep vsync on.

I only recently saw a discussion about how variable refresh rate should be
exposed in KMS UABI. Therefore I believe there is no UABI for it yet, which
means that nothing on DRM KMS can make use of it yet.

> > However, Weston will never tear on presenting to screen, and Weston will
> > never sample from a client buffer that has not finished drawing (implicit
> > fencing).
> 
> Windows (at last with Intel drivers) lets rendering tear if application is
> both fullscreen and has disabled Vsync.  I think this is reasonable, as
> compositor shouldn't then be involved.  Disabling Vsync kind of means that
> application and/or user doesn't care about tearing.

I think that could be possible to implement, provided two things:
- the compositor has a working composite bypass path and the fullscreen window
hits it
- the compositor actually knows the applications has "disabled vsync"
(currently there is no way to know reliably)

However, disabling vsync by setting eglSwapInterval=0 is not a reliable
indication that the application actually wants to tear: Wayland applications
can do it to be sure that eglSwapBuffers does not block unnecessarily while
they still want vsync and handle frame syncing manually.


Do you have ideas how to fix the issues you reported?

I'm not sure what to do. An application posts a GPU task that is so long that
it forces the compositor to miss the vblank, decimating the compositor's
framerate. We could protect the compositor's framerate from being decimated by
a) not using client buffers that are not finished drawing (with explicit
fences), and b) have the compositor GPU task pre-empt any applications GPU
tasks. We'd need both to ensure the compositor can update in time, but it won't
change the fact that the compositor will only update once for each vblank.

However, solution a) probably has the drawback that if the application is
unthrottled and hammering the compositor with new frames, the compositor might
never have a finished client buffer when it repaints because the client has
replaced it with a new one already. So the compositor would have to hold on to
some buffer to ensure it gets finished and can be shown.


Then again, I question the sensibility of optimizing a system for unnatural
benchmarks in the first place. I really want to push the world away from the
"maximize fps at all costs" mentality that means that games waste power by
drawing frames that will never be shown.

VR would probably be a very good setting to improve the display pipeline: it
demands vsync, high framerate (because the actual displays are high framerate),
and low latency. I think would be much better to optimize for that instead of
traditional benchmarks that don't care if a frame gets shown. With VR there is
simply no room to waste power by drawing frames you never see.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-bugs/attachments/20180604/8f53246c/attachment.html>