<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 23, 2019 at 7:30 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 class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 23, 2019 at 4:49 PM Kenneth Graunke <<a href="mailto:kenneth@whitecape.org" target="_blank">kenneth@whitecape.org</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 Monday, April 22, 2019 6:29:43 PM PDT Marek Olšák wrote:<br>
> From: Marek Olšák <<a href="mailto:marek.olsak@amd.com" target="_blank">marek.olsak@amd.com</a>><br>
> <br>
> for better CPU-GPU parallelism<br>
> ---<br>
>  src/gallium/state_trackers/dri/dri_drawable.c | 20 +++++++++----------<br>
>  1 file changed, 10 insertions(+), 10 deletions(-)<br>
> <br>
> diff --git a/src/gallium/state_trackers/dri/dri_drawable.c b/src/gallium/state_trackers/dri/dri_drawable.c<br>
> index 26bfdbecc53..c1de3bed9dd 100644<br>
> --- a/src/gallium/state_trackers/dri/dri_drawable.c<br>
> +++ b/src/gallium/state_trackers/dri/dri_drawable.c<br>
> @@ -555,33 +555,33 @@ dri_flush(__DRIcontext *cPriv,<br>
>         *<br>
>         * This pulls a fence off the throttling queue and waits for it if the<br>
>         * number of fences on the throttling queue has reached the desired<br>
>         * number.<br>
>         *<br>
>         * Then flushes to insert a fence at the current rendering position, and<br>
>         * pushes that fence on the queue. This requires that the st_context_iface<br>
>         * flush method returns a fence even if there are no commands to flush.<br>
>         */<br>
>        struct pipe_screen *screen = drawable->screen->base.screen;<br>
> -      struct pipe_fence_handle *fence;<br>
> +      struct pipe_fence_handle *oldest_fence, *new_fence = NULL;<br>
>  <br>
> -      fence = swap_fences_pop_front(drawable);<br>
> -      if (fence) {<br>
> -         (void) screen->fence_finish(screen, NULL, fence, PIPE_TIMEOUT_INFINITE);<br>
> -         screen->fence_reference(screen, &fence, NULL);<br>
> -      }<br>
> +      st->flush(st, flush_flags, &new_fence);<br>
>  <br>
> -      st->flush(st, flush_flags, &fence);<br>
> +      oldest_fence = swap_fences_pop_front(drawable);<br>
> +      if (oldest_fence) {<br>
> +         screen->fence_finish(screen, NULL, oldest_fence, PIPE_TIMEOUT_INFINITE);<br>
> +         screen->fence_reference(screen, &oldest_fence, NULL);<br>
> +      }<br>
>  <br>
> -      if (fence) {<br>
> -         swap_fences_push_back(drawable, fence);<br>
> -         screen->fence_reference(screen, &fence, NULL);<br>
> +      if (new_fence) {<br>
> +         swap_fences_push_back(drawable, new_fence);<br>
> +         screen->fence_reference(screen, &new_fence, NULL);<br>
>        }<br>
>     }<br>
>     else if (flags & (__DRI2_FLUSH_DRAWABLE | __DRI2_FLUSH_CONTEXT)) {<br>
>        st->flush(st, flush_flags, NULL);<br>
>     }<br>
>  <br>
>     if (drawable) {<br>
>        drawable->flushing = FALSE;<br>
>     }<br>
<br>
It seems like this will let us submit one more batch before throttling,<br>
which is a little like increasing the throttle value from 2 to 3...but<br>
not exactly.  I'm not sure I have an opinion on which is better...<br></blockquote><div><br></div><div>"Wait then flush" adds latency (input lag) to the unflushed frame.</div><div>"Flush then wait" doesn't add latency.<br></div></div></div></blockquote><div><br></div><div>Actually, if it has to wait, there is already large input lag, so I guess this patch doesn't change anything other than increasing the number. I'll drop it.</div><div><br></div><div>Marek</div></div></div>