On Tue, 2009-08-18 at 14:46 -0400, Kristian Høgsberg wrote: > On Tue, Aug 18, 2009 at 1:36 PM, Thomas Hellström<tho...@shipmail.org> wrote: > > Kristian Høgsberg wrote: > >> > >> On Tue, Aug 18, 2009 at 3:52 AM, Thomas Hellström<tho...@shipmail.org> > >> wrote: > >> > >>> > >>> Kristian Høgsberg wrote: > >>> > >>>> > >>>> By sending an event back on the file descriptor we allow users of the > >>>> API to wait on the flip to finish in a standard poll or select > >>>> mainloop, where it can handle input from other sources while waiting. > >>>> If you rely on fences, the application will block when it tries to > >>>> access the buffers protected by the fence, and is unable to handle > >>>> input from other sources while it's blocking. > >>>> > >>>> > >>> > >>> Yes. you're right. How is the flip_finished event typically used by user > >>> space? > >>> Is it mostly for convenience or is it a must have? > >>> > >> > >> In the server we use the event to wake up the client who calls > >> glXSwapBuffer(). We block the client (SuspendClient) if it tries to > >> draw before the swap is complete and wake it up again when we get the > >> event from drm. See the dri2-swapbuffers branch in xorg/xserver git > >> for details. > >> > > > > So in the case where you have the command submission inserting relevant > > barriers (like hardware barriers in the Unichrome case, or fence class > > barriers in the general TTM fence-aware driver case, this notification is > > not really necessary since the flip is guaranteed to happen before any other > > rendering commands that touch the buffers in question. > > > > So modulo the flip timing notifications, the flip_finished event can be sent > > already when the flip is scheduled. Are the flip timing notifications > > required to be accurate? If so we have a slight problem, because we don't > > unnecessarily want to put clients to sleep, and we don't know when the flip > > has happened until it has actually happened. > > We don't put clients to sleep until they try to render to the new > backbuffer. For direct rendering this happens when the client calls > DRI2GetBuffers() after having called DRI2SwapBuffers(). If the flip > is not yet finished at that time, we restart the X request and suspend > the client. When the drm event fires it is read by the ddx driver, > which then calls DRI2SwapComplete() which will wake the client up > again. For AIGLX, we suspend the client in __glXForceCurrent(), but > the wakeup happens the same way.
DRI2GetBuffers() is the wrong place to do this though, it'll probably cause a lot of (most?) apps to block on the previous SwapBuffers before getting a chance of batching up the rendering commands for the next frame, draining the GPU pipeline. If it turns out that blocking on command stream submission / BO mapping is a problem for AIGLX - IME so far with doing something like this for DRI2CopyRegion throttling, it shouldn't be - maybe the DRM event mechanism can be used there. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
