On 01/09/16 02:05 PM, Jason Ekstrand wrote: > > > On Wed, Aug 31, 2016 at 7:00 PM, Michel Dänzer <mic...@daenzer.net > <mailto:mic...@daenzer.net>> wrote: > > On 31/08/16 11:21 PM, Jason Ekstrand wrote: > > On Aug 19, 2016 12:07 AM, "Michel Dänzer" <mic...@daenzer.net > <mailto:mic...@daenzer.net> > > <mailto:mic...@daenzer.net <mailto:mic...@daenzer.net>>> wrote: > >> From: Michel Dänzer <michel.daen...@amd.com > <mailto:michel.daen...@amd.com> > > <mailto:michel.daen...@amd.com <mailto:michel.daen...@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. > 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. > 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev