Re: [PATCH] drm/i915/display: Allow async flips on planes with no framebuffer changes

["Michel Dänzer" <michel.daenzer@mailbox.org>]

On 19.07.25 17:52, Ville Syrjälä wrote:
> On Sat, Jul 19, 2025 at 02:16:22AM +0200, Xaver Hugl wrote:
>> Am Do., 10. Juli 2025 um 22:21 Uhr schrieb Ville Syrjälä
>> <ville.syrjala@linux.intel.com>:
>>>
>>> On Mon, Jul 07, 2025 at 03:41:20PM +0000, Naveen Kumar wrote:
>>>> Allow asynchronous page flips on planes that either lack a framebuffer or
>>>> retain the same framebuffer, as long as no plane properties are modified.
>>>>
>>>> This avoids unnecessary failures in async flip paths when the update is
>>>> effectively a no-op, improving compatibility with some compositors.
>>>
>>> IMO what we want to do is make the drm core filter out all the garbage
>>> from the commit. That way the driver would only see the planes that are
>>> supposed to actually participate in the async flip.
>>
>> That sounds like a good goal, but I think it'll need some extra care
>> to avoid regressions. For example, "no-op" pageflips must still
>> trigger pageflip events, and affect the refresh rate with adaptive
>> sync.
> 
> Not for async commit via the atomic ioctl. That's where I'd want
> the filtering.
> 
> For sync commit nothing can really be filtered by the core code
> because side effects must be observed, and only the driver knows
> what all the side effects are.

I agree with Xaver.


In general, the DRM_MODE_PAGE_FLIP_ASYNC flag should affect only whether or not a plane assignment can take effect outside of vertical blank. That's true even with VRR. Current UAPI is that any commit with any state for a CRTC (or a plane bound to it) must trigger a refresh cycle on it ASAP with VRR.


With DRM_MODE_PAGE_FLIP_EVENT, an event must be sent even for "no-op" changes, or user space may get stuck waiting for the event.


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast