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. Either way, for DRI2 the notification doesn't need to be accurate, but the later we send it, the later we wake up the client, the less time the client will have to render the next frame. Of course, if you're willing to block the command queue on the flip, you can send the event as soon as the vsync barrier and swap commands have been queued and everything should be fine. But with the drm event, we have the option of not blocking the hw queue on the flip for hw that lets us do vsynced page flips outside the command queue (on intel hw it's just a register write, and the hw latches the new address and loads it on the next vsync). Does your hw not have a vsync interrupt either? We don't fire an interrupt from the command queue, we just program the flip and then send the event from the vsync interrup. cheers, Kristian ------------------------------------------------------------------------------ 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
