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

[Axel Davy]

On 26/04/2019 20:40, Marek Olšák wrote:
> On Fri, Apr 26, 2019 at 12:56 PM Axel Davy <davyaxel0 at gmail.com 
> <mailto:davyaxel0 at gmail.com>> wrote:
>
>     On 26/04/2019 10:08, Michel Dänzer wrote:
>     > On 2019-04-26 4:06 a.m., Marek Olšák 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.
>     > Nice idea. Not sure offhand about all ramifications, but
>     certainly worth
>     > a go.
>     >
>     >
>     >> 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;
>     > This might be slightly misleading, as there can still be two
>     frames in
>     > flight (on the GPU) at the same time. Might be better to leave
>     this at 2
>     > (so Nine isn't affected) and adjust its treatment in
>     > src/gallium/state_trackers/dri/dri_drawable.c .
>     >
>     >
>     Checking what gallium nine does currently, it seems we already do
>     flush
>     then wait,
>     however we call swap_fences_pop_front and swap_fences_push_back in
>     the
>     reverse order compared to your patch.
>     We compensate by taking PIPE_CAP_MAX_FRAMES_IN_FLIGHT + 1
>
>     In conclusion, with the proposed patch, gl and nine should have
>     the same
>     behaviour (and thus if gl benefits from a value of 1, nine should
>     as well).
>     I haven't have noticed input lag, I guess I have to test on heaven if
>     you see a difference.
>     How can I slow down my gpu to test that ? I use to use the
>     /sys/kernel/debug/dri/0/ vars to force low dpm, but it doesn't
>     seem to
>     be possible anymore as the related files are gone (rx480) ?
>
>
> I set maximum settings, windowed, resolution: custom, and I type in 
> the 4K resolution (I don't have a 4K monitor). When it's running, I 
> enable wireframe. It should be pretty slow.
>
> Marek


I couldn't notice any performance difference (card at low or high dpm - 
somehow the vars were still there, I was looking at the wrong place),
with and without the change and gallium nine. I couldn't notice a change 
in lag either (slowest I had was around 20 fps, which may not be the 
best to see that).

I'm fine with this change affecting nine.


Axel

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