Re: [Intel-gfx] [RFC] DRI2 swapbuffers (yes yet again)

[Ville S. <sy...@sc...>]

On Thu, Apr 30, 2009 at 08:49:12AM -0700, Jesse Barnes wrote:
> 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?

Well I guess it satisfies the requirement that flips will never happen
less than interval frames apart but if the application is flipping at a
slower rate anyway you still delay each flip by interval frames even
though there is no real need to do so. So it increases the latency a
bit. Also if/when you add support for queueing multiple flips the code
needs to be changed anyway to use the previous flip rather than when the
current flip was queued as the reference.

> > 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.

Well, I consider 1 more important since it makes tear-free rendering
w/o additional delays possible. But anyways both seem to have some
value so ideally both should be supported.

> > 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.

What's needed is rather next top field or next bottom field. If you
combine that with supporting interval (should be useful when queueuing
up several frames using 3:2 pulldown sequence) then there seems to be a
need for something more than just a single number.

-- 
Ville Syrjälä
sy...@sc...
http://www.sci.fi/~syrjala/