Leif Delgass wrote:
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.

I also committed my fixes for calling glXSwapBuffers without a bound context. This also enables MESA_swap_frame_usage on MGA, R100, and R200.




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

Reply via email to