On Fri, 1 May 2009 14:13:16 +0300 Ville Syrjälä <syrj...@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ä <syrj...@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 ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
