On 25.03.2016 04:51, Adam Jackson wrote: > On Thu, 2016-03-24 at 07:22 -0600, Keith Packard wrote: >> Michel Dänzer <[email protected]> writes: >>> From: Michel Dänzer <[email protected]> >>> >>> This code was added to deal with the driver present hook failing, in >>> which case we need to wait for the next MSC before executing the >>> presentation. >>> >>> However, it could also take effect in cases where the driver incorrectly >>> thinks the current MSC matches the target one (e.g. due to the kernel >>> interface only supporting 32-bit MSC values), in which case it could >>> result in the presentation getting requeued over and over. >>> >>> To prevent such issues, check specifically for the target MSC >>> immediately following the current MSC. >> Yeah, I think this is reasonable. I wondered if we should use a broader >> range than == 1, but really that's the only case that's interesting; >> either the flip vblank is getting executed in the MSC it was supposed >> to, in which case vblank->target_msc will be exactly crtc_msc+1, or it's >> being done late, in which case that will have passed and we'll copy it >> immediately. > > Huh. That actually means we're pretty close to supporting > GLX_EXT_swap_control_tear properly. Nice.
present_pixmap() currently basically hardcodes the GLX_EXT_swap_control_tear semantics: It only uses a synchronous flip or vblank wait if the target MSC is in the future, otherwise it falls back to an asynchronous flip or an immediate copy. We'd actually have to change it to support pre-GLX_EXT_swap_control_tear semantics (e.g. without PresentOptionAsync), if there's demand for that. > remote: I: patch #78156 updated using rev > 3b385105b2d19a1c55e9779ae88d775185eea231. > remote: I: 1 patch(es) updated to state Accepted. > To ssh://git.freedesktop.org/git/xorg/xserver > 8ac0e05..3b38510 master -> master Thanks! -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
