On Tue, 2008-11-25 at 11:31 -0800, Jesse Barnes wrote: > DRI2 is about to land in the Intel driver, so we've been thinking about how > to > deal with the last missing piece: vertical blank synchronized buffer swaps. > I > think there are a few of problems to solve here: > 1) swap buffers should be asynchronous (i.e. it should let the app continue > rendering the next frame, not block until the swap completes, since that > would defeat the whole purpose of double buffering) > 2) swap buffers in general shouldn't just let the app run flat out (i.e. > apps typically want to block until at least one of their frames is > displayed, configurable with the swap control extension) > 3) in a composited environment the compositor decides when the frames are > actually displayed, so we can't just do direct vblank waits in the app > like we do today
I agree on 1 and 3 but not clearly on 2. I think actually letting the app run nearly flat out is probably a fine plan. > I think the typical use case is a double buffered app doing glXSwapBuffers > between frames, expecting the function to return immediately unless the > buffer > being swapped to hasn't been displayed yet. That will allow it to continue > drawing as soon as possible, which should allow it to render another frame > before the next vertical blank period even in the face of scheduling latency. No, traditionally in swap of frame n, you wait for swap of frame n-1, so that you get full concurrency instead of letting both gpu and cpu spend some time idle. vblank syncing introduced waiting for vsync for the display of frame n and then dispatching it. > Currently, DRI2 glXSwapBuffers ends up in the DDX CopyRegion hook, which at > this point simply does a GC CopyArea. Kristian has a patch to allow for > swaps > synchronized to vertical blank, using a separate queue in the i915 DRM > driver, > but that only addresses problem (1). > > To handle problems (2) and (3) it seems like we need a way for the > compositing > manager to signal to the server/DDX that the front buffer has been updated > with the most recent buffers from the currently running GL apps. Kristian > thought we might be able to use the compositor's damage notifier for this; if > the DDX knew which one the compositor was using, it could wait until it was > clear before allowing subsequent buffer swaps to continue. > > Comments on this? In other environments (for example specific EGL back ends) > some other synchronization mechanism will be necessary. In the case of > Wayland, I think the compositor has its own copy of things, so it can simply > allow the swap to continue once it has a copy of the latest buffer. I don't like this plan. If my app has a new frame all ready to go, I want it to get displayed the next time the compositor wakes up to do a vblank-synced composite, not wait for the compositor to grab the stale frame before continuing. In the world I imagine, the app's running nearly flat-out (waiting only for getting its n-1 frame completed), getting damage posted as it "swaps" (flips front/back BO handles), and the compositor's picking up the last swapped frame when it wakes up to prepare the next frame to get displayed. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
-- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
