<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">On 26/04/2019 20:40, Marek Olšák wrote: </div> <blockquote type="cite" cite="mid:CAAxE2A7wMXZui_GG+TmMEoie1MZtF5yCiZg9XkwQZhqFcT4D9Q@mail.gmail.com"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <div dir="ltr"> <div class="gmail_quote"> <div dir="ltr" class="gmail_attr">On Fri, Apr 26, 2019 at 12:56 PM Axel Davy <<a href="mailto:davyaxel0@gmail.com" moz-do-not-send="true">davyaxel0@gmail.com</a>> wrote: </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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 <<a href="mailto:marek.olsak@amd.com" target="_blank" moz-do-not-send="true">marek.olsak@amd.com</a>> >> >> 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) ? </blockquote> <div> </div> <div>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.</div> <div> </div> <div>Marek </div> </div> </div> </blockquote> 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 </body> </html>