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

[Jesse Barnes]

On Fri, 1 May 2009 14:13:16 +0300
Ville Syrjälä <syrjala at sci.fi> wrote:

> On Thu, Apr 30, 2009 at 02:39:57PM -0700, Jesse Barnes wrote:
> > On Fri, 1 May 2009 00:25:54 +0300
> > Ville Syrjälä <syrjala at sci.fi> wrote:
> > > > 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.
> > 
> > Ah yeah I see what you mean, so if the app renders a frame and then
> > queues a flip to happen in two refreshes, but doesn't queue its next
> > frame until one refresh after the last one, you'll get a stutter,
> > with 2 refreshes between the first two frames, and 3 between the
> > next two.
> 
> Yeah.
> 
> > If the app checks the frame count though, it could compensate and
> > lower its frame frequency to something it can render at a fixed
> > rate, as well as sending in a proper interval value.
>  
> If you mean that it should set the interval on some long term
> observation about it's rendering speed then I agree. If say half of
> the frames took 0.9 frame counts to render and half of them took 1.2
> frame counts to render then the application could just set interval
> to 2 and get smoother animation than it would get with interval 1.
> 
> But if you mean that it should check the current frame count on each
> flip and base the interval value on that then I disagree because
> getting the frame count and queueing the flip would not be atomic so
> the calculated interval value might be incorrect by the time the flip
> is queued. This sort of thing would only work if the flip ioctl would
> take an absolute frame count value for the flip, and then it would
> also need to return the current frame count to the application so
> that the application could calculate the next flip's absolute value
> correctly (in case the previous flip actually happened after the
> specific absolute value).

Yeah, I was thinking about the former.  But we could do the latter as
well.  We get a count at submit time, and it would be easy to return
that...

> > Ok.  I'd better add whatever's needed to the ioctl now so we don't
> > have to make a new one later.  You think just an odd/even field
> > flag would be sufficient?
> 
> I think it needs three modes: top field first, bottom field first, or
> either field first. The 'either field first' option can be used when
> the source material is progressive. It doesn't really make sense to
> demand flips to happen on any specific field in that case.
> 
> Also I suggest using the top/bottom terms rather than the odd/even
> terms because odd/even are somewhat ambiguous.
> 
> So I suppose adding one flag for top field first, and a second flag
> for bottom field first would be sufficient. Setting both flags could
> be considered an error, and setting neither flag would allow the flip
> to happen on either field. Does that sound reasonable?

Sure, that sounds fine.  We've still got 30 flags left. :)

-- 
Jesse Barnes, Intel Open Source Technology Center