On 2019-04-26 4:06 a.m., Marek Olšák wrote: > From: Marek Olšák <marek.ol...@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.
Nice idea. Not sure offhand about all ramifications, but certainly worth a go. > 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; This might be slightly misleading, as there can still be two frames in flight (on the GPU) at the same time. Might be better to leave this at 2 (so Nine isn't affected) and adjust its treatment in src/gallium/state_trackers/dri/dri_drawable.c . -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
