[Mesa-dev] [PATCH] st/dri: decrease input lag by syncing sooner in SwapBuffers

[Marek Olšák]

This patch might improve performance, because less submitted unfinished
work means less used memory by the unfinished work.

Marek

On Mon, Apr 29, 2019 at 11:07 AM Michel Dänzer <michel at daenzer.net> wrote:

> On 2019-04-27 6:13 p.m., Rob Clark wrote:
> > On Thu, Apr 25, 2019 at 7:06 PM Marek Olšák <maraeo at gmail.com> wrote:
> >>
> >> From: Marek Olšák <marek.olsak at amd.com>
> >>
> >> It's done by:
> >> - decrease the number of frames in flight by 1
> >> - flush before throttling in SwapBuffers
> >>   (instead of wait-then-flush, do flush-then-wait)
> >>
> >> The improvement is apparent with Unigine Heaven.
> >>
> >> Previously:
> >>     draw frame 2
> >>     wait frame 0
> >>     flush frame 2
> >>     present frame 2
> >>
> >>     The input lag is 2 frames.
> >>
> >> Now:
> >>     draw frame 2
> >>     flush frame 2
> >>     wait frame 1
> >>     present frame 2
> >>
> >>     The input lag is 1 frame. Flushing is done before waiting, because
> >>     otherwise the device would be idle after waiting.
> >>
> >> Nine is affected because it also uses the pipe cap.
> >> ---
> >>  src/gallium/auxiliary/util/u_screen.c         |  2 +-
> >>  src/gallium/state_trackers/dri/dri_drawable.c | 20 +++++++++----------
> >>  2 files changed, 11 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/src/gallium/auxiliary/util/u_screen.c
> b/src/gallium/auxiliary/util/u_screen.c
> >> index 27f51e0898e..410f17421e6 100644
> >> --- a/src/gallium/auxiliary/util/u_screen.c
> >> +++ b/src/gallium/auxiliary/util/u_screen.c
> >> @@ -349,21 +349,21 @@ u_pipe_screen_get_param_defaults(struct
> pipe_screen *pscreen,
> >>     case PIPE_CAP_MAX_VARYINGS:
> >>        return 8;
> >>
> >>     case PIPE_CAP_COMPUTE_GRID_INFO_LAST_BLOCK:
> >>        return 0;
> >>
> >>     case PIPE_CAP_COMPUTE_SHADER_DERIVATIVES:
> >>        return 0;
> >>
> >>     case PIPE_CAP_MAX_FRAMES_IN_FLIGHT:
> >> -      return 2;
> >> +      return 1;
> >
> > would it be safer to leave the current default and let drivers opt-in
> > to the lower # individually?  I guess triple buffering would still be
> > better for some of the smaller gpu's?
>
> This patch doesn't prevent triple buffering. The application can still
> prepare up to one frame worth of GPU commands before the GPU has
> finished processing the commands of the previous frame (while the
> pre-previous frame is being displayed).
>
> I just think the term "in flight" should maybe be defined a bit better,
> but it's not a blocker and could be done in a follow-up patch.
>
>
> --
> Earthling Michel Dänzer               |              https://www.amd.com
> Libre software enthusiast             |             Mesa and X developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20190429/12d2687b/attachment.html>