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