-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michel Dänzer wrote: > On Fri, 2009-09-04 at 12:17 -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. >> >> 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 > > Waiting in the X server will make it quite unlikely that the client will > be notified within a reasonable timeframe from when vertical blank > actually occurs. Won't this jeopardize the usefulness of the > functionality?
I'm not very fond of doing a round-trip to the server for these either. It seems like we want a DRM way do this directly. There are a lot of potential race issues, though. How do we handle the case where the client waits for frame N+5, and on frame N+2 the window moves to a different CRTC? >> 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) > > Maybe the X server could trigger a DRM event that the client could wait > for directly, or something like that. Jesse and I had discussed a future extension that would allow the creation of a GLsync object from a MSC or SBC wait request. I think using a DRM event would be the only reasonable way to implement that. Adding a way for one process to signal the DRM event that another process is waiting on isn't a big stretch. >> - compositor interaction; in the compositor case the display server >> will be incrementing frame count based on compositor drawing rather >> than vblank events > > I think that's a bad idea, as it will confuse apps if the compositor > misses a frame or renders the app window more than once per frame. That's a good point. The interaction with the compositor here is complex. Ugh. :( -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqkdC0ACgkQX1gOwKyEAw+AvACgg/f7FBUaEbvdDDH9sqElEBX9 duMAn0Eh3KioHID26gubLRpLMiNvTqkN =yzBS -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ 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
