<div dir="ltr"><div>If there is no other feedback, I'll push this tomorrow.</div><div><br></div><div>Marek<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 29, 2019 at 6:12 PM Marek Olšák <<a href="mailto:maraeo@gmail.com">maraeo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>This patch might improve performance, because less submitted unfinished work means less used memory by the unfinished work.<br></div><div><br></div><div>Marek<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 29, 2019 at 11:07 AM Michel Dänzer <<a href="mailto:michel@daenzer.net" target="_blank">michel@daenzer.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2019-04-27 6:13 p.m., Rob Clark wrote:<br>
> On Thu, Apr 25, 2019 at 7:06 PM Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>> wrote:<br>
>><br>
>> From: Marek Olšák <<a href="mailto:marek.olsak@amd.com" target="_blank">marek.olsak@amd.com</a>><br>
>><br>
>> It's done by:<br>
>> - decrease the number of frames in flight by 1<br>
>> - flush before throttling in SwapBuffers<br>
>>   (instead of wait-then-flush, do flush-then-wait)<br>
>><br>
>> The improvement is apparent with Unigine Heaven.<br>
>><br>
>> Previously:<br>
>>     draw frame 2<br>
>>     wait frame 0<br>
>>     flush frame 2<br>
>>     present frame 2<br>
>><br>
>>     The input lag is 2 frames.<br>
>><br>
>> Now:<br>
>>     draw frame 2<br>
>>     flush frame 2<br>
>>     wait frame 1<br>
>>     present frame 2<br>
>><br>
>>     The input lag is 1 frame. Flushing is done before waiting, because<br>
>>     otherwise the device would be idle after waiting.<br>
>><br>
>> Nine is affected because it also uses the pipe cap.<br>
>> ---<br>
>>  src/gallium/auxiliary/util/u_screen.c         |  2 +-<br>
>>  src/gallium/state_trackers/dri/dri_drawable.c | 20 +++++++++----------<br>
>>  2 files changed, 11 insertions(+), 11 deletions(-)<br>
>><br>
>> diff --git a/src/gallium/auxiliary/util/u_screen.c b/src/gallium/auxiliary/util/u_screen.c<br>
>> index 27f51e0898e..410f17421e6 100644<br>
>> --- a/src/gallium/auxiliary/util/u_screen.c<br>
>> +++ b/src/gallium/auxiliary/util/u_screen.c<br>
>> @@ -349,21 +349,21 @@ u_pipe_screen_get_param_defaults(struct pipe_screen *pscreen,<br>
>>     case PIPE_CAP_MAX_VARYINGS:<br>
>>        return 8;<br>
>><br>
>>     case PIPE_CAP_COMPUTE_GRID_INFO_LAST_BLOCK:<br>
>>        return 0;<br>
>><br>
>>     case PIPE_CAP_COMPUTE_SHADER_DERIVATIVES:<br>
>>        return 0;<br>
>><br>
>>     case PIPE_CAP_MAX_FRAMES_IN_FLIGHT:<br>
>> -      return 2;<br>
>> +      return 1;<br>
> <br>
> would it be safer to leave the current default and let drivers opt-in<br>
> to the lower # individually?  I guess triple buffering would still be<br>
> better for some of the smaller gpu's?<br>
<br>
This patch doesn't prevent triple buffering. The application can still<br>
prepare up to one frame worth of GPU commands before the GPU has<br>
finished processing the commands of the previous frame (while the<br>
pre-previous frame is being displayed).<br>
<br>
I just think the term "in flight" should maybe be defined a bit better,<br>
but it's not a blocker and could be done in a follow-up patch.<br>
<br>
<br>
-- <br>
Earthling Michel Dänzer               |              <a href="https://www.amd.com" rel="noreferrer" target="_blank">https://www.amd.com</a><br>
Libre software enthusiast             |             Mesa and X developer<br>
</blockquote></div>
</blockquote></div>