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 <mic...@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 <mar...@gmail.com> 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. > >> > >> 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 >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
