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). > > > > 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. > > 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? -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ ------------------------------------------------------------------------------ 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
