[PATCH 09/11] modesetting: Implement PRIME syncing as a sink

Michel Dänzer michel at daenzer.net
Mon Nov 30 17:53:56 PST 2015


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


More information about the xorg-devel mailing list