On Aug 31, 2016 11:39 PM, "Michel Dänzer" <<a href="mailto:michel@daenzer.net">michel@daenzer.net</a>> wrote: > > On 01/09/16 02:05 PM, Jason Ekstrand wrote: > > > > > > On Wed, Aug 31, 2016 at 7:00 PM, Michel Dänzer <<a href="mailto:michel@daenzer.net">michel@daenzer.net</a> > > <mailto:<a href="mailto:michel@daenzer.net">michel@daenzer.net</a>>> wrote: > > > > On 31/08/16 11:21 PM, Jason Ekstrand wrote: > > > On Aug 19, 2016 12:07 AM, "Michel Dänzer" <<a href="mailto:michel@daenzer.net">michel@daenzer.net</a> <mailto:<a href="mailto:michel@daenzer.net">michel@daenzer.net</a>> > > > <mailto:<a href="mailto:michel@daenzer.net">michel@daenzer.net</a> <mailto:<a href="mailto:michel@daenzer.net">michel@daenzer.net</a>>>> wrote: > > >> From: Michel Dänzer <<a href="mailto:michel.daenzer@amd.com">michel.daenzer@amd.com</a> <mailto:<a href="mailto:michel.daenzer@amd.com">michel.daenzer@amd.com</a>> > > > <mailto:<a href="mailto:michel.daenzer@amd.com">michel.daenzer@amd.com</a> <mailto:<a href="mailto:michel.daenzer@amd.com">michel.daenzer@amd.com</a>>>> > > >> > > >> 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: > > > > <a href="https://cgit.freedesktop.org/mesa/mesa/commit/?id=f7a355556ef5fe23056299a77414f9ad8b5e5a1d">https://cgit.freedesktop.org/mesa/mesa/commit/?id=f7a355556ef5fe23056299a77414f9ad8b5e5a1d</a> > > 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 | <a href="http://www.amd.com">http://www.amd.com</a> > Libre software enthusiast | Mesa and X developer