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 ------------------------------------------------------- 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
