From: Jesse B. <jb...@vi...> - 2009-04-30 15:49:16
|
On Thu, 30 Apr 2009 11:36:55 +0300 Ville Syrjälä <sy...@sc...> wrote: > On Wed, Apr 29, 2009 at 06:02:59PM -0700, Jesse Barnes wrote: > > On Wed, 29 Apr 2009 15:09:33 -0700 > > Jesse Barnes <jb...@vi...> wrote: > > > I'm still working through mutlihead issues on the kernel side; the > > > flip waits should wait for *both* vblank events before completing > > > the flip. But other than that, I'm pretty happy with things. > > > > This incremental set fixes up the multihead handling and adds swap > > interval support as a bonus. It's nice to see flipping & no > > tearing on two heads at once! > > Your interval handling seems to be too harsh. In case you wanted > something that can implement GLX_SGI_swap_control then AFAICS the > interval should only specify the minimum number of frames that must > pass between two swaps. Your code appears to always delay the flip by > exactly interval frames. The completion won't happen until at least 'interval' frames have passed since the flip was queued, so I think the semantics match? > Also it seems that the cases where you have more than one back buffer > were not yet fully considered. I can see two use cases for this: > > 1) Triple buffering with the purpose of going faster than the monitor > refresh rate w/o tearing. Here you would never wait for any flips and > if a new flip is scheduled before the previous was completed then the > previous flip should be considered immediately complete so the buffer > can be reused. > > 2) Scheduling multiple flips in advance while maintaining the swap > interval. This way the application could render several frames in > advance and just queue the flips in the driver to gain a little more > breathing room for the rendering. Yeah, I intended for the DRI2 protocol I added to handle this case, but there's no code for it yet. I think it could be done purely in the 2D driver though. I think case (2) is probably the most important here, but (1) is pretty easy to do as well. > And as a final missing piece I would mention interlaced output with > proper field parity, but I'm not sure if you're interested in such > things for this API. We could treat the 'interval' as meaning odd/even in that case. I.e. an interval of 1 would mean 'next field' and 2 would mean 'start of next frame', but yeah there's not much support for interlacing in the kernel atm. -- Jesse Barnes, Intel Open Source Technology Center |