[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 #13 from Eero Tamminen <eero.t.tamminen at intel.com> ---
(In reply to Pekka Paalanen from comment #11)
> (In reply to Eero Tamminen from comment #9)
>> * All (3D) benchmarks run with Vsync disabled, and often games are run with
>> Vsync disabled too.
> 
> If one benchmarks the GPU, why does it matter what goes on the screen? You
> cannot update the screen any faster than its refresh rate anyway.

Some reasons:

* Customers think that jerky output from benchmarks looks bad (especially if
they're their own benchmarks)

* When screen output doesn't visually correspond to what benchmark is
reporting, people can start thinking that somebody is cheating

* For 3D driver benchmarking one should use offscreen tests, but things
modeling real applications often have only onscreen version.  When compositor
overhead is basically random (instead of 60Hz, or benchmark FPS), you cannot
calculate/factor it

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


> If you are benchmarking the full gfx stack all the way to screen, then run
> the application with vsync and if it consistently maintains the full refresh
> rate, measure the GPU load to get a performance number.

While GPU load can give you some magnitude of performance, and for some really
trivial 3D operations [1], it could even be used to estimate the performance,
it's not really useful (accurate enough) for real 3D applications.

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


> I have a feeling that games are just poor. It's physically impossible to
> update the screen faster than the screen refreshes anyway. If screen update
> rate affects input latency for the game state, the game engine is badly
> designed. Traditionally it's been easy to just pump up the fps to work
> around all problems (and sell tons of expensive hardware) rather than doing
> something sensible like drawing at the right time instead of continuously
> hammering.
>
> 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.)


> 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.

-- 
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/20180601/42f746b6/attachment.html>