Re: [Dri-devel] [PATCH] Fixes for GLX_SGI_video_sync
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
Re: [Dri-devel] [PATCH] Fixes for GLX_SGI_video_sync
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
Re: [Dri-devel] [PATCH] Fixes for GLX_SGI_video_sync
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
