<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - With Vsync disabled, Weston almost halves *visible* frame update rate, compared to X desktop" href="https://bugs.freedesktop.org/show_bug.cgi?id=106736#c11">Comment # 11</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - With Vsync disabled, Weston almost halves *visible* frame update rate, compared to X desktop" href="https://bugs.freedesktop.org/show_bug.cgi?id=106736">bug 106736</a> from <a class="email" href="mailto:ppaalanen@gmail.com" title="Pekka Paalanen <ppaalanen@gmail.com>"> Pekka Paalanen</a> <pre>(In reply to Eero Tamminen from <a href="show_bug.cgi?id=106736#c9">comment #9</a>) > * 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. 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. 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. > * Those are often run in fullscreen where it wouldn't matter if compositing > were disabled, but Weston has regressed in that with modifier support, see > bug: 106732 That is temporary from the beginning. We'll get it back. > As there's a workaround, and <a class="bz_bug_link bz_status_NEW " title="NEW - DRM backend does not buffer support modifiers for composition bypass" href="show_bug.cgi?id=106732">bug 106732</a> will fix the main issue with this, I > changed this to low/minor. > > > > repaint-window should be the lowest possible value where the compositor > > still makes the vblank deadline, to reduce application-to-screen latency. > > Ok, so prioritizing compositor frames wouldn't help, only repaint value does. > > Do you happen to know, is Compiz (clearly) better at this because it uses > higher latency value? Or does it adapt the value based on previous > application frame timings? I don't know what compiz does. I can guess though: - composite bypass for fullscreen works - it repaints ASAP - it tears in presenting - it tears in reading the application frame If you set repaint-window to 500 ms (anything equal or greater to refresh period), you will have Weston repainting ASAP. Usually that means as soon as DRM pageflip event comes, as your benchmarking app has posted a new frame by then. Btw. this scheme will become miserable as soon as you have more than one app updating. 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).</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>