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

[Axel Davy]

hi,

I haven't done enough testing to have a full understanding of the issue, 
but it seems there could be a regression with gallium nine.

One user is reporting on irc huge slowdowns with d3d8 games (using the 
d3d8to9 wrapper) when using vsync. Reverting fixes the issues.

I don't know exactly why vsync would have issues.

Another thing though is that many d3d9 games do their own throttling, 
and if our throttling is stricter, maybe the game multithreading could 
be perturbed.
All in all, this needs more testing with gallium nine.

To prevent possible regression for next release, I'll force 
PIPE_CAP_MAX_FRAMES_IN_FLIGHT to be clamped to 2 at least for gallium nine.


Might be worth trying to see if gl could be affected.

Yours,

Axel

On 02/05/2019 03:19, Marek Olšák wrote:
> 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 
> <mailto: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
>     <mailto: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 <mailto:maraeo at gmail.com>> wrote:
>         >>
>         >> From: Marek Olšák <marek.olsak at amd.com
>         <mailto: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
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20190526/6b1dbb32/attachment-0001.html>