If there is no other feedback, I'll push this tomorrow. Marek
On Mon, Apr 29, 2019 at 6:12 PM Marek Olšák <mar...@gmail.com> wrote: > 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
