From: Jesse B. <jb...@vi...> - 2008-11-25 20:18:38
|
On Tuesday, November 25, 2008 11:44 am Eric Anholt wrote: > 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. Sure it should be allowed, but I think many apps won't want that. Your video player for example actually wants its frames to be displayed, and in many cases rendering more than the refresh rate is wasteful. But anyway that's what we have swap control for. > > 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. Right. "buffer being swapped to" == frame n - 1 is what I was trying to say. You draw to the back buffer, do a swapbuffers, and unless the last back buffer you swapped to front was displayed, you end up blocking at that point. > 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. I don't disagree, that's what I was trying to say. Obviously I didn't say it very well. -- Jesse Barnes, Intel Open Source Technology Center |