Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Michel Dänzer" <michel.daenzer@mailbox.org>
To: "Murthy, Arun R" <arun.r.murthy@intel.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	"Vivi, Rodrigo" <rodrigo.vivi@intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Tvrtko Ursulin <tursulin@ursulin.net>,
	"xaver.hugl@kde.org" <xaver.hugl@kde.org>,
	"andrealmeid@igalia.com" <andrealmeid@igalia.com>,
	"Kumar, Naveen1" <naveen1.kumar@intel.com>,
	"Syrjala, Ville" <ville.syrjala@intel.com>,
	Dmitry Baryshkov <lumag@kernel.org>
Cc: "dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH RFC v3 0/7] Async Flip in Atomic ioctl corrections
Date: Mon, 12 Jan 2026 12:34:01 +0100	[thread overview]
Message-ID: <dd0a089c-6591-4fc3-b14e-5acc1c59cf8e@mailbox.org> (raw)
In-Reply-To: <83e50bd4-de11-4298-bab9-7a5255b0c5ca@intel.com>

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 <michel.daenzer@mailbox.org>
>>>> 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.


>>> This series doesn’t solve that, but rather accommodate multiple plane async flips in an atomic ioctl and allowing disabling of a sync plane which is already enabled. There has been a long discussion in the gitlab(https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13834) on this.
>> AFAICT that's a false-positive rejection of commits which don't actually change cursor plane state.
> 
> https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13834#note_2855843

Not sure what you're trying to say here / how that comment contradicts what I wrote.


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

  reply	other threads:[~2026-01-12 11:34 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-08  9:43 [PATCH RFC v3 0/7] Async Flip in Atomic ioctl corrections Arun R Murthy
2026-01-08  9:43 ` [PATCH [RFC] v3 1/7] drm/atomic/plane: Add plane property for async flip Arun R Murthy
2026-01-08  9:43 ` [PATCH [RFC] v3 2/7] drm/atomic/plane: create async flip property for plane Arun R Murthy
2026-01-08  9:43 ` [PATCH [RFC] v3 3/7] drm/atomic: Re-route the async flip based on the flag Arun R Murthy
2026-01-08  9:43 ` [PATCH [RFC] v3 4/7] drm/atomic: Move the plane property check for async flip to atomic_check Arun R Murthy
2026-01-08  9:43 ` [PATCH [RFC] v3 5/7] drm/atomic: Allow planes with NULL fb along with async flip Arun R Murthy
2026-01-09  9:43   ` Michel Dänzer
2026-01-09 11:08     ` Murthy, Arun R
2026-01-09 11:23       ` Michel Dänzer
2026-01-12  8:26         ` Murthy, Arun R
2026-01-12 11:24           ` Michel Dänzer
2026-01-12 15:20             ` Murthy, Arun R
2026-01-12 15:25               ` Michel Dänzer
2026-01-12 16:03               ` Xaver Hugl
2026-01-13  2:47                 ` Murthy, Arun R
2026-01-08  9:43 ` [PATCH [RFC] v3 6/7] drm/atomic: flip_done signal for planes Arun R Murthy
2026-01-08  9:43 ` [PATCH [RFC] v3 7/7] drm/i915/irq: Enable flip_done for each plane on async flip Arun R Murthy
2026-01-08  9:53 ` ✓ CI.KUnit: success for " Patchwork
2026-01-08 10:35 ` ✓ Xe.CI.BAT: " Patchwork
2026-01-08 13:09 ` ✓ Xe.CI.Full: " Patchwork
2026-01-09  9:43 ` [PATCH RFC v3 0/7] Async Flip in Atomic ioctl corrections Michel Dänzer
2026-01-09 11:07   ` Murthy, Arun R
2026-01-09 11:22     ` Michel Dänzer
2026-01-12  8:23       ` Murthy, Arun R
2026-01-12 11:34         ` Michel Dänzer [this message]
2026-01-12 15:35           ` Murthy, Arun R
2026-02-11  5:48           ` Murthy, Arun R
2026-02-11  8:57             ` Michel Dänzer
2026-02-11 13:38               ` Murthy, Arun R
2026-02-11 13:51                 ` Michel Dänzer
2026-02-11 13:58                   ` Murthy, Arun R

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dd0a089c-6591-4fc3-b14e-5acc1c59cf8e@mailbox.org \
    --to=michel.daenzer@mailbox.org \
    --cc=airlied@gmail.com \
    --cc=andrealmeid@igalia.com \
    --cc=arun.r.murthy@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=lumag@kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=naveen1.kumar@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=simona@ffwll.ch \
    --cc=tursulin@ursulin.net \
    --cc=tzimmermann@suse.de \
    --cc=ville.syrjala@intel.com \
    --cc=xaver.hugl@kde.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox