On Fre, 2012-12-14 at 12:03 -0500, Ilija Hadzic wrote: > On Fri, Dec 14, 2012 at 4:55 AM, Michel Dänzer <[email protected]> wrote: > >> + /* > >> + * CRTC is in DPMS off state, fallback to blit, but pace the > >> + * application at the rate that roughly approximates the > >> + * nominal frame rate of the relevant CRTC > >> + */ > >> + if (!radeon_crtc_is_enabled(crtc)) { > >> + TimerSet(NULL, 0, nominal_vblank_period, radeon_dri2_deferred_swap, > >> + swap_info); > >> + *target_msc = 0; > >> + return TRUE; > >> + } > > > > This will always wait for (at least) nominal_vblank_period milliseconds > > before performing the swap, but a significant part of that (or even more > > time) might have passed already since the last swap of the drawable. You > > could keep track of the previous swap time (from the event tv_(u)sec > > values or GetTimeInMillis()) in a drawable private and only wait for the > > amount of time actually necessary. > > I guess you mean CRTC private.
I mean what I wrote. > There is no drawable private So add one. > and such information would not be per-drawable anyway (it would be per-CRTC). Eh? The MSC and related values are properties of the drawable, not the CRTC (there is no concept of a CRTC in GLX/DRI2 at all). Only tracking this per CRTC will break with several clients synchronizing to the same CRTC. > Regarding taking target_msc into account, I agree, but I have a > question: is setting > target_msc to zero (to return it to the caller) acceptable action ? As > far as I can tell, > it should be fine: if schedule_swap resets target_msc, in the next > call the caller > "resynchronizes" (i.e. if I return zero in current call, it will > typically be 1 in the next call). I don't know all the ramifications, but can't you just leave it (or maybe update it to reflect the current fake MSC, at least if we missed the target)? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer _______________________________________________ xorg-driver-ati mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-driver-ati
