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. /Thomas ------------------------------------------------------------------------------ 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
