On 2/11/26 14:38, Murthy, Arun R wrote: > On 11-02-2026 14:27, Michel Dänzer wrote: >> On 2/11/26 06:48, Murthy, Arun R wrote: >>>> On 1/12/26 09:23, Murthy, Arun R wrote: >>>>> On 09-01-2026 16:52, Michel Dänzer wrote: >>>>>> On 1/9/26 12:07, Murthy, Arun R wrote: >>>>>>>> From: Michel Dänzer <[email protected]> On 1/8/26 10:43, >>>>>>>> Arun R Murthy wrote: >>>>>>>>> struct drm_crtc_state { >>>>>>>>> /** >>>>>>>>> * @async_flip: >>>>>>>>> * >>>>>>>>> * This is set when DRM_MODE_PAGE_FLIP_ASYNC is set in the >>>> legacy >>>>>>>>> * PAGE_FLIP IOCTL. It's not wired up for the atomic >>>>>>>>> IOCTL itself yet. >>>>>>>>> */ >>>>>>>>> bool async_flip; >>>>>>>>> >>>>>>>>> In the existing code the flag async_flip was intended for the >>>>>>>>> legacy PAGE_FLIP IOCTL. But the same is being used for atomic IOCTL. >>>>>>>>> As per the hardware feature is concerned, async flip is a plane >>>>>>>>> feature and is to be treated per plane basis and not per pipe basis. >>>>>>>>> For a given hardware pipe, among the multiple hardware planes, one >>>>>>>>> can go with sync flip and other 2/3 can go with async flip. >>>>>>>> FWIW, this kind of mix'n'match doesn't seem useful with current >>>>>>>> UAPI, since no new commit can be made for the async plane(s) before >>>>>>>> the previous commit for the sync plane(s) has completed, so the >>>>>>>> async plane(s) can't actually have higher update rate than the sync >>>>>>>> one(s). >>>>>>> That’s right, such mix and match flips will still consume vblank time >>>>>>> for >>>> flipping. >>>>>> Does a plane property really make sense for this then? >>>>> As per the hardware this async flip is per plane basis and not per crtc. >>>> That's not really relevant. >>>> >>>> >>>>> Not that I am trying to clean up this. Recently AMD added async support on >>>> overlays as well for which few other hacks were added. The checks that we >>>> do >>>> for async flip were all done in place of copy the objs/properties, but it >>>> actually is >>>> supposed to be done in the check_only() part of the drm core code. This was >>>> the limitation with the existing implementation. >>>> >>>> Those implementation details can be changed without changing UAPI. >>>> >>>> >>>>> As per hardware the async flip is associated with the plane, hence >>>>> changing it >>>> to a plane property. >>>> >>>> A plane property would only really be needed for mixing async & sync plane >>>> updates in a single commit. Since that's currently not usefully possible >>>> due to >>>> other restrictions of the UAPI, the DRM_MODE_PAGE_FLIP_ASYNC flag which >>>> affects the commit as a whole is fine at this point. >>>> >>> Sorry for getting back late on this, took some time to collaborate all the >>> feedbacks. >>> >>> We can depict the below 3 scenarios based on the discussions so far. >>> 1. KMD can allow a mix of sync and async only if there is a disable plane >>> req on sync and no plane update on sync flips along with async flips(maybe >>> on multiple planes). KMD will send the flipdone after sync plane disable >>> is done. (Basically flipdone will send at vblank) >> What would be the point of allowing that? The compositor can't do the next >> commit before the sync plane has turned off anyway, so it can just as well >> do that in a sync commit and the async plane updates in separate commits >> later. > For an async flip to start, the 1st async flip will consume almost a vblank > time, so if compositor does a sync flip on a plane along with sync flip to > disable the plane, the next async flip will still consume a vblank time. If > KMD allows disabling of a sync plane with async flip then we can overcome > this.
The HW limitation you describe makes frequent switching between sync & async flips infeasible anyway, so it's doubtful that an additional sync flip before async flips would really make a difference in practice. So this would essentially complicate the UAPI to avoid a vendor-specific issue, for dubious benefit. >>> 3. With multiple plane async flips, KMD send flip done per plane basis to >>> the user. (async flag per plane from user) >>> 4. With supporting a mix of sync and async flips, should KMD allow them and >>> send one flipdone for async flips and one flipdone for sync flips. >> Again not sure what would be the point of 3 or 4, since the compositor can't >> do the next commit before all planes have updated anyway. > Upon compositor getting a flipdone on the async flip, the buffers will be > unpinned and this can be used by the compositor for rendering or for > preparing the next flip. I have a hard time seeing that make any practical difference. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
