From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Pekka Paalanen <ppaalanen@gmail.com>
Cc: andrealmeid@igalia.com, daniel.vetter@ffwll.ch,
amd-gfx@lists.freedesktop.org,
wayland-devel@lists.freedesktop.org, mwen@igalia.com,
dri-devel@lists.freedesktop.org, alexander.deucher@amd.com,
hwentlan@amd.com, nicholas.kazlauskas@amd.com, joshua@froggi.es
Subject: Re: KMS atomic state sets, full vs. minimal (Re: [PATCH v3 0/6] Add support for atomic async page-flips)
Date: Fri, 30 Sep 2022 18:58:32 +0300 [thread overview]
Message-ID: <YzcSKN+3MS0Dg3mF@intel.com> (raw)
In-Reply-To: <YzcPBfLBNzfbHG5W@intel.com>
On Fri, Sep 30, 2022 at 06:45:09PM +0300, Ville Syrjälä wrote:
> On Fri, Sep 30, 2022 at 06:37:00PM +0300, Pekka Paalanen wrote:
> > On Fri, 30 Sep 2022 18:09:55 +0300
> > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> >
> > > That would actively discourage people from even attempting the
> > > "just dump all the state into the ioctl" approach with async flips
> > > since even the props whose value isn't even changing would be rejected.
> >
> > About that.
> >
> > To me it looks like just a classic case of broken communication.
> >
> > The kernel developers assume that of course userspace will minimize the
> > state set to only those properties that change, because...?
> >
> > Userspace developers think that of course the kernel will optimize the
> > state set into minimal changes, because the kernel actually has the
> > authoritative knowledge of what the current state is, and the driver
> > actually knows which properties are costly and need to be optimized and
> > which ones don't matter. It has never even occurred to me that the
> > kernel would not compare next state to current state.
> >
> > No-one ever documented any expectations, did they?
>
> Do you really want that for async flips? Async flips can't be
> done atomically with anything else, so why are you even asking
> the kernel to do that?
Also what if you want plane 1 to do an async flip, and plane 2 to do
a sync flip? With the single async flag per commit you will end up
with one of the following results:
plane 1 plane 2 outcome
can async can async async flip on both planes (totally not what you wanted)
can async can't async -EINVAL (what you actually wanted but got unfairly rejected)
can't async can async -EINVAL
can't async can't async -EINVAL
Those last two are actually reasonable outcomes since the plane
where you did want to async flip didn't support it. But the
first two are just nonsense results.
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2022-09-30 15:58 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-29 18:43 [PATCH v3 0/6] Add support for atomic async page-flips Simon Ser
2022-09-29 18:43 ` Simon Ser
2022-09-29 18:43 ` [PATCH v3 1/6] drm: document DRM_MODE_PAGE_FLIP_ASYNC Simon Ser
2022-09-29 18:43 ` Simon Ser
2022-09-29 18:43 ` [PATCH v3 2/6] amd/display: only accept async flips for fast updates Simon Ser
2022-09-29 18:43 ` Simon Ser
2022-09-29 18:43 ` [PATCH v3 3/6] drm: introduce drm_mode_config.atomic_async_page_flip_not_supported Simon Ser
2022-09-29 18:43 ` Simon Ser
2022-09-30 13:53 ` Ville Syrjälä
2022-09-30 13:56 ` Simon Ser
2022-09-30 14:02 ` Ville Syrjälä
2022-09-29 18:43 ` [PATCH v3 4/6] drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits Simon Ser
2022-09-29 18:43 ` Simon Ser
2022-09-29 18:43 ` [PATCH v3 5/6] drm: introduce DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP Simon Ser
2022-09-29 18:43 ` Simon Ser
2022-09-29 18:44 ` [PATCH v3 6/6] amd/display: indicate support for atomic async page-flips on DC Simon Ser
2022-09-29 18:44 ` Simon Ser
2022-09-30 13:42 ` [PATCH v3 0/6] Add support for atomic async page-flips Harry Wentland
2022-09-30 13:42 ` Harry Wentland
2022-09-30 13:52 ` Ville Syrjälä
2022-09-30 14:19 ` Ville Syrjälä
2022-09-30 15:09 ` Ville Syrjälä
2022-09-30 15:37 ` KMS atomic state sets, full vs. minimal (Re: [PATCH v3 0/6] Add support for atomic async page-flips) Pekka Paalanen
2022-09-30 15:37 ` Pekka Paalanen
2022-09-30 15:45 ` Ville Syrjälä
2022-09-30 15:45 ` Ville Syrjälä
2022-09-30 15:58 ` Ville Syrjälä [this message]
2022-10-03 8:48 ` Pekka Paalanen
2022-10-03 8:48 ` Pekka Paalanen
2022-10-03 9:04 ` Ville Syrjälä
2022-10-03 9:04 ` Ville Syrjälä
2022-10-13 16:02 ` [PATCH v3 0/6] Add support for atomic async page-flips Simon Ser
2022-10-17 14:35 ` André Almeida
2022-10-17 14:35 ` André Almeida
2022-10-28 12:36 ` André Almeida
2022-10-28 12:36 ` André Almeida
2022-11-17 8:58 ` Simon Ser
2023-01-05 16:01 ` Simon Ser
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=YzcSKN+3MS0Dg3mF@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=andrealmeid@igalia.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=hwentlan@amd.com \
--cc=joshua@froggi.es \
--cc=mwen@igalia.com \
--cc=nicholas.kazlauskas@amd.com \
--cc=ppaalanen@gmail.com \
--cc=wayland-devel@lists.freedesktop.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.