On Wed, 28 May 2003, Dieter Nützel wrote: > Am Dienstag, 13. Mai 2003 18:07 schrieb Leif Delgass: > > Attached are two patches: the first fixes problems with GLX_SGI_video_sync > > in the drivers and common vblank code and adds a common driGetMSC32() > > function in vblank.c. The second patch adds a '-sync' option to glxgears > > that will use the extension to sync to the refresh. > > > > Here are more details on the first patch: > > > > - Added a generic driGetMSC32() to vblank.c, which gets the current MSC by > > calling drmWaitForVBlank() with a relative wait of 0 (i.e., don't wait, > > just return the current MSC value). I should point out that since the > > vblank counter in the kernel is an unsigned int rather than an unsigned > > long, this will return a 32-bit value (then cast to an int64_t) even for > > 64-bit platforms (not sure if this is true for all platforms, but I > > checked it on Alpha and Sparc64 on the compile farm and it's 32-bit). > > > > - The radeon and r200 drivers' implementations of GetMSC was using the > > wrong counter (frame age instead of vblank counter), and mga was doing a > > wait for "absolute 0" rather than a relative wait for 0. I changed all > > the drivers to use the new generic implementation. One possible problem > > of using the counter for both the SGI/OML extensions is that the OML > > version wants the counter incremented for each field with an interlaced > > mode, and the SGI version does not. > > > > - I added support to r128 for GLX_SGI_swap_control, GLX_SGI_video_sync, > > and GLX_MESA_swap_control. GLX_SGI_video_sync can be exported by any > > driver using the common vblank code by installing callbacks to the two > > generic functions (driWaitMSC32 and driGetMSC32) in the DriverAPI struct. > > > > - Since some of the drivers already had C99 designated initializers for > > some of the new DriverAPI members, I changed those drivers to use them for > > initializing all the members. gcc supports this as an extension to C89, > > but I'm not sure if this will be an issue when merging into the XFree86 > > tree. > > > > - I fixed a couple of problems with the driWaitForMSC32() implementation, > > some of which cropped up when it's used for the SGI extension instead of > > the OML extension. First, I made the local vars unsigned ints and added > > explicit casts on the paramters passed as int64_t to unsigned int, in > > order to match up with the unsigned int sequence returned from the kernel > > and make it more clear (to me at least) what's going on. Second, I made > > the function behave as expected for SGI_sync_control when target_msc == 0 > > (which is what is passed in from glxcmds.c for the SGI extension), i.e. > > don't wait for the target, just proceed to the test against the divisor > > and remainder. This should be fine for the OML version if zero is passed > > as the target, as it works as if the target was missed (and you're pretty > > much gauranteed to always miss 0 for a 64-bit counter which is supposed to > > never roll over). The last fix affects both extensions: the calculation > > of the next target MSC (from the divisor/remainder) needed a tweak: > > MSC - (MSC % divisor) + remainder gives you the refresh closest to the > > current one, but it can be _after_ the current one, so we only need to add > > divisor if that value is less than or equal to the current MSC. > > > > > > Anyone have comments and/or suggestions? Obviously, there are still > > 32-/64-bit issues to work out. > > What about hits stuff? > > -Dieter
I committed this (minus the gears patch), so GLX_SGI_video_sync should be working for r200, radeon (r100), r128 and mga. The 32-/64-bit question is still an open one, though. -- Leif Delgass http://www.retinalburn.net ------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
