[Mesa-dev] [PATCH] loader/dri3: Overhaul dri3_update_num_back

[Jason Ekstrand]

On Aug 31, 2016 11:39 PM, "Michel Dänzer" <michel at daenzer.net> wrote:
>
> On 01/09/16 02:05 PM, Jason Ekstrand wrote:
> >
> >
> > On Wed, Aug 31, 2016 at 7:00 PM, Michel Dänzer <michel at daenzer.net
> > <mailto:michel at daenzer.net>> wrote:
> >
> >     On 31/08/16 11:21 PM, Jason Ekstrand wrote:
> >     > On Aug 19, 2016 12:07 AM, "Michel Dänzer" <michel at daenzer.net
<mailto:michel at daenzer.net>
> >     > <mailto:michel at daenzer.net <mailto:michel at daenzer.net>>> wrote:
> >     >> From: Michel Dänzer <michel.daenzer at amd.com <mailto:
michel.daenzer at amd.com>
> >     > <mailto:michel.daenzer at amd.com <mailto:michel.daenzer at amd.com>>>
> >     >>
> >     >> Always use 3 buffers when flipping. With only 2 buffers, we have
to wait
> >     >> for a flip to complete (which takes non-0 time even with
asynchronous
> >     >> flips) before we can start working on the next frame. We were
previously
> >     >> only using 2 buffers for flipping if the X server supports
asynchronous
> >     >> flips, even when we're not using asynchronous flips. This could
result
> >     >> in bad performance (the referenced bug report is an extreme
case, where
> >     >> the inter-frame stalls were preventing the GPU from reaching its
maximum
> >     >> clocks).
> >     >
> >     > Sorry for the post-push review but I don't usually pay much
attention to
> >     > the window system code.  In any case, I believe you're doing your
> >     > counting wrong.  When flipping with swapinterval=0, you need 4
buffers:
> >     >
> >     > 1. The buffer currently being scanned out  (will be released at
next vblank)
> >     > 2. The buffer X has queued for scanout but is waiting on vblank
> >
> >     s/vblank/flip/g, since async flips may not wait for vblank, but
yeah.
> >
> >     > 3. The buffer the application has just submitted which X will
queue next
> >     > of it doesn't get another before the window closes.
> >     > 4. The buffer the application is using for rendering.
> >     >
> >     > With only 3, you get a stall during that window in which X has
queued
> >     > another flip but we're waiting on vblank before the flip begins.
An I
> >     > missing something?
> >
> >     Nothing, except maybe the paragraph below stating that I couldn't
> >     measure any benefit from using 4 buffers. :) I'm not exactly sure
why,
> >     but I suspect it might be because even with just 3 buffers, the GPU
can
> >     always work on at least one frame ahead of time.
> >
> >     Also note that even before my change, we were only using 3 buffers
when
> >     the X driver supports async flips (with swap interval 0; only 2
buffers
> >     with swap interval > 0).
> >
> >
> > Yes, because with async flips you don't have a buffer sitting queued in
> > the kernel waiting to be flipped which you can't cancel.
>
> Actually, there is. Even async flips take non-0 time to complete.
>
>
> > that makes perfect sense.
>
> What exactly does? My change may not be perfect, but the logic before it
> was mostly backwards.

I think perhaps the problem here is that I don't know what you mean by
"async flips".  It's an X term that obviously does not mean what I thought
it meant.

> >     That said, I'd be interested in hearing about any test cases where 4
> >     buffers provide a significant boost over 3.
> >
> >
> > A little history that may be useful: Quadbuffering was originally added
> > for DRI3+present here:
> >
> >
https://cgit.freedesktop.org/mesa/mesa/commit/?id=f7a355556ef5fe23056299a77414f9ad8b5e5a1d
>
> So the commit message claims. If you look at the code after that change
> though, it's basically impossible to end up with 4 buffers (at least
> permanently), since it would require all these conditions to be true at
> the same:
>
> 1. priv->flipping (the last Present request was completed as a flip)
> 2. !(priv->present_capabilities & XCB_PRESENT_CAPABILITY_ASYNC) (the X
>    driver doesn't support async flips)
> 3. priv->swap_interval == 0
>
> Given 2, 1 & 3 are mutually exclusive.

I'm not seeing how 1 & 3 are mutually exclusive.  priv->swap_interval
doesn't seem to have anything to do with whether or not you're flipping.

> > Unfortunately, neither of those specify precise metrics.  Eero's bug had
> > some very concrete numbers.  Hopefully he can provide you with the
> > details you need for further analysis.
>
> Indeed. FWIW, my feeling is that my change most likely just exposed
> issues elsewhere.
>
>
> --
> Earthling Michel Dänzer               |               http://www.amd.com
> Libre software enthusiast             |             Mesa and X developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160901/592ae7f1/attachment-0001.html>