----- Forwarded message from Peter John Garrone <pgarr...@optusnet.com.au> -----
From: Peter John Garrone <pgarr...@optusnet.com.au> To: Jesse Barnes <jbar...@virtuousgeek.org> Subject: Re: [RFC] page flipping/buffer swap for DRI2 On Fri, Feb 13, 2009 at 04:44:08PM -0800, Jesse Barnes wrote: > 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. I incorrectly wrote software interrupt when I meant hardware interrupt, which is confusing, sorry. I would rephrase my own particular requirement as "Is the buffer flip to be implemented in the hardware, or implemented in software triggered by hardware interrupt?" The intel hardware has the ability to do a buffer swap in the hardware. However I believe that the current dri infrustructure works (see mesa/src/mesa/drivers/dri/intel/intel_swapbuffers.c:intelSwapBuffers) by flushing pending rendering commands, waiting for the appropriate vertical blank interrupt, then copying the opengl back buffer to the front buffer. This is a problem when the interrupt response is slow, or when the hardware graphics queue is not empty because other opengl applications are currently rendering, so the buffer swap is delayed, creating a tear generally near the top of the screen. I don't think this quite agrees with your outline, unless your patch set addresses this problem, which would be wonderful. I currently cope with this by poking the hardware to cause the two screens to interrupt at a particular phase, and synchronizing the two rendering threads to wait until both have accomplished their screen swaps. At high loads, however, the synchronization breaks down and tearing results, and it is never possible to completly eliminate tearing. > > > 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. That's fine. I would hope that in a dual-headed setup, each screen (or plane) can be individually full-screen. Sometimes fullscreen is interpreted as a single window covering both screens, which is not good for me. > > > 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. This appears to me to be what the code in intel_swapbuffers.c currently achieves. I'm grateful if you are creating an alternative for fullscreen applications, anyway. > > > 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 Peter Garrone ----- End forwarded message ----- ------------------------------------------------------------------------------ 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
