On Fri, 4 Sep 2009 13:25:43 -0700 Ian Romanick <i...@freedesktop.org> wrote:
> On Fri, Sep 04, 2009 at 12:17:20PM -0700, Jesse Barnes wrote: > > I've been working on coding up the server and client side of > > SGI_video_sync, OML_sync_control and SGI_swap_control. I came up > > with this set of new protocol (against the dri2-swapbuffers branch) > > to support the new requests. > > > > We still need to change the DRI2SwapBuffers request to handle the > > various OML bits before it gets merged. > > Do you have a proposal for what those changes would look like? We had > talked about a few different things previously. Yeah, just coded them up. DRI2SwapBuffers has a target_msc, divisor and remainder now, and returns a reply with the queued swap count. Pretty straightforward I think. > > To summarize: > > DRI2GetMSCReq - get MSC triple > > DRI2WaitMSCReq - wait on an MSC count or divisor/remainder > > DRI2WaitSBCReq - wait on a swap count or all pending swaps > > DRI2MSCReply - MSC triple (generated in response to any of the > > above) > > > > Kristian and I talked briefly about doing this client side using > > events to notify clients when their CRTC changes, but there are a > > few issues: > > - races between client blocking and other server events (DPMS, > > window movement) > > - compositor interaction; in the compositor case the display > > server will be incrementing frame count based on compositor drawing > > rather than vblank events > > so we thought a DRI2 solution was best here. These particular calls > > are expected to block frequently, so I don't think latency is as > > big a concern as with some other operations (like SwapBuffers, but > > it also has the second issue mentioned above, so needs to be server > > side). > > > > Comments? If these look ok I'll push them into the dri2-swapbuffers > > branch and fix up DRI2SwapBuffers with the rest of the OML fields. > > This looks good. I don't see any protocol to support > glXGetMscRateOML. Are we going to do that some other way? At first I thought we could get away with just using the existing XVidMode based code or by adding some xrandr code, but I don't think that's sufficient. In the composited case we'll probably want to get the update frequency from the compositor instead, so adding new protocol probably makes sense. -- Jesse Barnes, Intel Open Source Technology Center ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
