From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Xaver Hugl <xaver.hugl@kde.org>
Cc: Naveen Kumar <naveen1.kumar@intel.com>,
intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, mdaenzer@redhat.com,
sebastian.wick@redhat.com, jadahl@gmail.com
Subject: Re: [PATCH] drm/i915/display: Allow async flips on planes with no framebuffer changes
Date: Sat, 19 Jul 2025 18:52:42 +0300 [thread overview]
Message-ID: <aHu_SsrCUJTzPhmd@intel.com> (raw)
In-Reply-To: <CAFZQkGwKs04zJ0y2VuwVJkiKH6Z00dZoYGroWS6R=Qux_n0iJQ@mail.gmail.com>
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.
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2025-07-19 15:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-07 15:41 [PATCH] drm/i915/display: Allow async flips on planes with no framebuffer changes Naveen Kumar
2025-07-10 20:21 ` Ville Syrjälä
2025-07-19 0:16 ` Xaver Hugl
2025-07-19 15:52 ` Ville Syrjälä [this message]
2025-07-21 12:40 ` Michel Dänzer
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=aHu_SsrCUJTzPhmd@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jadahl@gmail.com \
--cc=mdaenzer@redhat.com \
--cc=naveen1.kumar@intel.com \
--cc=sebastian.wick@redhat.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;
as well as URLs for NNTP newsgroup(s).