This seems wrong to me -- the client doesn't need to sleep - all it's going to do is build a command buffer targeting the new backbuffer. There's no problem with that, it should be the preserve of the GPU scheduler (TTM or GEM) to ensure those commands (once submitted) don't get executed until the buffer is available - otherwise you're potentially pausing your application for no good reason. The app should be throttled if it gets more than a couple of frames ahead, but there should be 100% overlap with hardware otherwise.
If you need a solution that doesn't rely on the buffer manager, perhaps resort to triple-buffering, or else create a new buffer and return that in DRI2GetBuffers (and let the scanout one be freed once the flip is done). It seems like arbitrating command execution against on-hardware buffers should be the preserve of the kernel memory manager & other actors shouldn't be double-guessing that. Keith ________________________________________ From: Kristian Høgsberg [...@bitplanet.net] Sent: Tuesday, August 18, 2009 11:46 AM To: Thomas Hellström Cc: Kristian Høgsberg; Jesse Barnes; dri-de...@lists.sf.net Subject: Re: [PATCH] Add modesetting pageflip ioctl and corresponding drm event 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. ------------------------------------------------------------------------------ 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
