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

[Marek Olšák]

If there is no other feedback, I'll push this tomorrow.

Marek

On Mon, Apr 29, 2019 at 6:12 PM Marek Olšák <maraeo at 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 <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/20190501/b7e02666/attachment.html>