On Thu, 2008-09-11 at 11:59 -0400, Kristian Høgsberg wrote: > > > On Wed, 2008-09-10 at 14:16 -0400, Kristian Høgsberg wrote: > >> On Tue, Sep 9, 2008 at 1:34 PM, Michel Dänzer > >> <[EMAIL PROTECTED]> wrote: > >> > > >> > If the GLX implementation is to use DRI2CopyRegion for synchronization > >> > purposes, then the interface of the latter needs to be at least as > >> > expressive as the DRM synchronization interfaces currently used by the > >> > former. > >> > >> Could you give a quick summary of what those are and where you think > >> DRI2CopyRegion falls short? > > > > See e.g. intelScheduleSwap() in > > mesa/src/mesa/drivers/dri/intel/intel_buffers.c: > > > > * For the case of missing the target, chooses to accept tearing or > > execute the swap during the next vblank period (based on driconf > > vblank_mode). > > * Chooses the primary or secondary CRTC. > > * Needs the returned effective/expected sequence number to know if > > the target was hit or missed and to calculate the next target > > sequence number. > > > > The MSC related APIs as in mesa/src/mesa/drivers/dri/common/vblank.c > > also need to be consistent with the DRI2CopyRegion sequence numbers. So > > I think DRI2 would need to wrap the DRM_IOCTL_WAIT_VBLANK functionality > > as well (or be DRM specific, which would be unfortunate - and could > > still have issues like mapping the CRTC IDs between the DRM and DRI2 > > interfaces). > > So we need to be able to specify whether to drop a frame or postpone > it when we miss the target. I'm not happy about having to return the > effective swap sequence number...
What is your concern? > is there a way we can move the computation of the next target to the > server? Look at the GLX_OML_sync_control spec for example; if DRI2CopyRegion doesn't provide feedback, wouldn't we have to move most if not all the logic for this and similar extensions into the DRI2 server side? -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
