<div dir="ltr"><div>This patch might improve performance, because less submitted unfinished work means less used memory by the unfinished work. </div><div> </div><div>Marek </div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 29, 2019 at 11:07 AM Michel Dänzer <<a href="mailto:michel@daenzer.net" target="_blank">michel@daenzer.net</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2019-04-27 6:13 p.m., Rob Clark wrote: > On Thu, Apr 25, 2019 at 7:06 PM Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>> wrote: >> >> From: Marek Olšák <<a href="mailto:marek.olsak@amd.com" target="_blank">marek.olsak@amd.com</a>> >> >> 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 | <a href="https://www.amd.com" rel="noreferrer" target="_blank">https://www.amd.com</a> Libre software enthusiast | Mesa and X developer </blockquote></div>