On 01.12.2015 07:36, Alex Goins wrote: > >> Always scheduling an event for the next vblank means that the vblank >> interrupt can never be disabled, right? Might be better to trigger the >> next update when getting new damage if there's currently none. > > Yeah, I think so. I had to work around that for DPMS by disabling flipping > with > DPMS off and re-enabling it with DPMS on. > > Triggering the next update when getting new damage is certainly doable. > However, > there would have be some way to tell the sink to flip when the update is > finished. > > Since presenting is asynchronous, I currently do this by attaching a fence to > the buffer prior to presenting, and signaling it after. The sink immediately > attempts a flip after master->PresentTrackedFlippingPixmap() returns TRUE, but > for drivers that support it, the flip is blocked (hopefully asynchronously) by > the fence. I currently have pending patches adding fencing support to i915's > flipping paths. > > This method could theoretically be extended, attaching the fence even when > there > isn't damage, and signaling it after presenting in response to damage. In > practice, however, I think this could cause problems. > > While drmModePageFlip() is asynchronous and returns immediately, I've seen > drivers wait on page flips as part of other, synchronous, DRM calls. If we're > waiting on damage events in X to ultimately signal, this could cause a > deadlock > in the kernel. > > Moreover, problems would arise for drivers that do not support fencing page > flips. As it stands, it isn't that big of an issue because presenting almost > always finishes before the page flip. However, if we needed to wait for a > longer > period of time, those drivers would end up flipping to a stale buffer. > > Of course, I could just always present regardless of damage, but needless to > say > that's not ideal. The most universal solution I think would be to add another > sink ABI function for the source to use to trigger a flip after a deferred > present.
I meant that no flip should be submitted either while there's no damage. -- 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: http://lists.x.org/mailman/listinfo/xorg-devel
