On Fri, Apr 26, 2019 at 12:56 PM Axel Davy <davyax...@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.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. > > 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
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
