Thomas Hellström wrote: > Keith Whitwell wrote: >> 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. >> > I agree. > > It would be fairly trivial to use TTMs synchronization mechanisms to > put special fences on buffers with outstanding flips. These fences > signal when a "software flipper" engine has programmed a flip. Any > command submission involving these buffers while fenced will > effectively put the rendering client to sleep. Rendering to other > buffers, including a potential third buffer would continue > undisturbed. Pinning and unpinning of scanouts would take place at > command submission time as detailed before. > Of course, in the case of AIGLX, the X server might temporarily be put > to sleep, which might not be fully optimal. > > A "software flipper" engine would be a simple vblank irq handler that > flips and signals the flipper fence when the previous fences of the > buffers (if present) have signaled (to finish any outstanding > rendering before flipping). > > I guess GEM's buffer object busy lists be used to accomodate something > similar? > > /Thomas > Oh, and a fully-fledged GPU scheduler might of course temporarily buffer the hw commands without putting the client to sleep, just as Keith's suggests.
In any case there's a full range of hw and scheduler capabilities that won't require the X server to do scheduling and put clients to sleep. Why not leave this to the kernel? /Thomas > >> 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
