All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pekka Paalanen <ppaalanen@gmail.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: andrealmeid@igalia.com, Simon Ser <contact@emersion.fr>,
	dri-devel@lists.freedesktop.org,
	wayland-devel@lists.freedesktop.org, mwen@igalia.com,
	amd-gfx@lists.freedesktop.org, daniel.vetter@ffwll.ch,
	alexander.deucher@amd.com, hwentlan@amd.com,
	nicholas.kazlauskas@amd.com, joshua@froggi.es
Subject: 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:37:00 +0300	[thread overview]
Message-ID: <20220930183700.6cf64900@eldfell> (raw)
In-Reply-To: <YzcGw9myJotLRTVl@intel.com>

[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]

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?


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Pekka Paalanen <ppaalanen@gmail.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: andrealmeid@igalia.com, dri-devel@lists.freedesktop.org,
	wayland-devel@lists.freedesktop.org, mwen@igalia.com,
	amd-gfx@lists.freedesktop.org, daniel.vetter@ffwll.ch,
	alexander.deucher@amd.com, hwentlan@amd.com,
	nicholas.kazlauskas@amd.com, joshua@froggi.es
Subject: 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:37:00 +0300	[thread overview]
Message-ID: <20220930183700.6cf64900@eldfell> (raw)
In-Reply-To: <YzcGw9myJotLRTVl@intel.com>

[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]

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?


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2022-09-30 15:37 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       ` Pekka Paalanen [this message]
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:45         ` Ville Syrjälä
2022-09-30 15:45           ` Ville Syrjälä
2022-09-30 15:58           ` Ville Syrjälä
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=20220930183700.6cf64900@eldfell \
    --to=ppaalanen@gmail.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=andrealmeid@igalia.com \
    --cc=contact@emersion.fr \
    --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=ville.syrjala@linux.intel.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.