On Friday, February 13, 2009 4:18 pm Peter John Garrone wrote: > In reply to Jesse Barnes post. > I'm not on top of the finer details, being a consumer rather than a > developer. I have the following queries: > > 1) Is the buffer flip to be synchronous in the hardware, or to be > implemented as a software interrupt?
I'm not sure what you mean... The flip is queued in the hardware ring, and delayed by hardware until the vertical blank interval starts. So in that sense the hardware takes care of it for us (we don't rely on an interrupt to get the bits on the screen). We do require an interrupt, however, to know when the flip has occurred. This lets us know that it's ok to start drawing on the new back buffer, since it's no longer being displayed to the user. > 2) By fullscreen, do you mean covering one or all screens in a multi-headed > display? It's hard coded to deal with one screen in this patchset, but potentially needs to flip both heads in a shared (cloned or extended desktop) configuration. > 3) If fullscreen means covering an individual screen in a multi-headed > display, will it be possible to have multiple simultaneous fullscreen > tear-free applications? Yes, it should be possible. > 4) Will non-fullscreen applications be tear-free? Maybe. If you're running a compositing manager that always swaps the whole screen (like the hacked version of compiz I've been using for testing does), then any non-DRI apps running under it will be tear-free. DRI apps will need special treatment, which I haven't implemented yet. > To be honest, the speed of the window manager is not a big issue for me. > Tearing is. In production mode, efficient fullscreen output mode is > desirable. In development mode, having the output into manageable > re-sizeable windows is nicer. > > The only way I can see non-tearing non-fullscreen > applications working is with triple-buffer. i.e. a kernel screen flyback > interrupt copies a screen-full from the multi-headed working buffer to a > plane buffer, schedules that plane buffer to be swapped upon the next > flyback, and triggers approptiate returns from the application swap-buffer > function calls. I assume this is triple-buffer because there is the large > possibly virtual working buffer and also two plane buffers for each screen. That would be one way of handling non-fullscreen apps. Another way would be to queue front buffer blits from such apps to occur during the vertical blank period. That's not as reliable (nor easy to implement) as full page flipping though, but has the advantage of just blitting over a small area of the screen, which will preserve most of the compressed framebuffer (if present), saving power. > However a fullscreen application should be able to override this on an > individual screen basis, rendering directly into the non-output display > plane, and scheduling it to be swapped upon the N'th flyback. Right, that's basically what this patchset enables. When a buffer swap comes in for a full screen back/front combo, a flip is queued rather than a blit executed. > Apologies for sounding preachy, I simply outline my own analysis and am > wondering how it is possible for a window manager, which must output to > a larger virtual space, could be regarded as a good candidate for > double-buffering as you suggest. No that's fine; I'd like more eyes and comments on this patchset. A compositing window manager is a special case, since it may span multiple screens like you say, but issue a single glXSwapBuffers call for its whole rendering area. In that case we can queue flips on each head to update the base pointers, and only allow drawing to the new backbuffer when both flips have completed. That should avoid tearing on either head, at the cost of a little more complexity in the swapbuffers implementation. -- Jesse Barnes, Intel Open Source Technology Center ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
