From: Pekka Paalanen <ppaalanen@gmail.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: DRI Development <dri-devel@lists.freedesktop.org>,
Simon Ser <contact@emersion.fr>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
stable <stable@vger.kernel.org>,
Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [Intel-gfx] [PATCH] drm: document and enforce rules around "spurious" EBUSY from atomic_commit
Date: Wed, 23 Sep 2020 12:55:02 +0300 [thread overview]
Message-ID: <20200923125502.4735f720@eldfell> (raw)
In-Reply-To: <CAKMK7uFvaMRK3Zh-s21OG=V3sPQZjn7Z_WQaNMcL=_R36enR2g@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1369 bytes --]
On Wed, 23 Sep 2020 11:26:39 +0200
Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> I'm really not awake yet ...
>
> On Wed, Sep 23, 2020 at 10:17 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> >
> > On Tue, 22 Sep 2020 20:18:34 +0200
> > Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >
> > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > > pull in arbitrary other resources, including CRTCs (e.g. when
> > > reconfiguring global resources).
> > If yes, and *if* userspace is single-threaded wrt. to KMS updates,
> > that might offer a way to work around it in userspace. But if userspace
> > is flipping other CRTCs from other threads, TEST_ONLY commit does not
> > help because another thread may cut in and make a CRTC busy.
>
> This is not a legit programming model for atomic. An atomic commit is
> always relative to the current state. If that state changes, then you
> need to re-run your TEST_ONLY commit. So multiple threads changing
> state in parallel isn't really a good idea anyway. Minimally we'd need
> some kind of TEST_ONLY pile-up, so you can validate a change assuming
> another commit has already happened. That's even harder than deep
> queues on the commit side, we'd probably need full rollback of
> commits.
Yes, very good point. I forgot that for a moment.
Thanks,
pq
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
WARNING: multiple messages have this Message-ID (diff)
From: Pekka Paalanen <ppaalanen@gmail.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: DRI Development <dri-devel@lists.freedesktop.org>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
stable <stable@vger.kernel.org>,
Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH] drm: document and enforce rules around "spurious" EBUSY from atomic_commit
Date: Wed, 23 Sep 2020 12:55:02 +0300 [thread overview]
Message-ID: <20200923125502.4735f720@eldfell> (raw)
In-Reply-To: <CAKMK7uFvaMRK3Zh-s21OG=V3sPQZjn7Z_WQaNMcL=_R36enR2g@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1369 bytes --]
On Wed, 23 Sep 2020 11:26:39 +0200
Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> I'm really not awake yet ...
>
> On Wed, Sep 23, 2020 at 10:17 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> >
> > On Tue, 22 Sep 2020 20:18:34 +0200
> > Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >
> > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > > pull in arbitrary other resources, including CRTCs (e.g. when
> > > reconfiguring global resources).
> > If yes, and *if* userspace is single-threaded wrt. to KMS updates,
> > that might offer a way to work around it in userspace. But if userspace
> > is flipping other CRTCs from other threads, TEST_ONLY commit does not
> > help because another thread may cut in and make a CRTC busy.
>
> This is not a legit programming model for atomic. An atomic commit is
> always relative to the current state. If that state changes, then you
> need to re-run your TEST_ONLY commit. So multiple threads changing
> state in parallel isn't really a good idea anyway. Minimally we'd need
> some kind of TEST_ONLY pile-up, so you can validate a change assuming
> another commit has already happened. That's even harder than deep
> queues on the commit side, we'd probably need full rollback of
> commits.
Yes, very good point. I forgot that for a moment.
Thanks,
pq
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Pekka Paalanen <ppaalanen@gmail.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: "Intel Graphics Development" <intel-gfx@lists.freedesktop.org>,
"DRI Development" <dri-devel@lists.freedesktop.org>,
"Daniel Stone" <daniel@fooishbar.org>,
"Simon Ser" <contact@emersion.fr>,
stable <stable@vger.kernel.org>,
"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
"Daniel Vetter" <daniel.vetter@intel.com>
Subject: Re: [PATCH] drm: document and enforce rules around "spurious" EBUSY from atomic_commit
Date: Wed, 23 Sep 2020 12:55:02 +0300 [thread overview]
Message-ID: <20200923125502.4735f720@eldfell> (raw)
In-Reply-To: <CAKMK7uFvaMRK3Zh-s21OG=V3sPQZjn7Z_WQaNMcL=_R36enR2g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1369 bytes --]
On Wed, 23 Sep 2020 11:26:39 +0200
Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> I'm really not awake yet ...
>
> On Wed, Sep 23, 2020 at 10:17 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> >
> > On Tue, 22 Sep 2020 20:18:34 +0200
> > Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >
> > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > > pull in arbitrary other resources, including CRTCs (e.g. when
> > > reconfiguring global resources).
> > If yes, and *if* userspace is single-threaded wrt. to KMS updates,
> > that might offer a way to work around it in userspace. But if userspace
> > is flipping other CRTCs from other threads, TEST_ONLY commit does not
> > help because another thread may cut in and make a CRTC busy.
>
> This is not a legit programming model for atomic. An atomic commit is
> always relative to the current state. If that state changes, then you
> need to re-run your TEST_ONLY commit. So multiple threads changing
> state in parallel isn't really a good idea anyway. Minimally we'd need
> some kind of TEST_ONLY pile-up, so you can validate a change assuming
> another commit has already happened. That's even harder than deep
> queues on the commit side, we'd probably need full rollback of
> commits.
Yes, very good point. I forgot that for a moment.
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-09-23 9:55 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-22 18:18 [Intel-gfx] [PATCH] drm: document and enforce rules around "spurious" EBUSY from atomic_commit Daniel Vetter
2020-09-22 18:18 ` Daniel Vetter
2020-09-22 18:18 ` Daniel Vetter
2020-09-22 18:57 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2020-09-22 19:22 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-09-22 19:22 ` [Intel-gfx] [PATCH] " Daniel Stone
2020-09-22 19:22 ` Daniel Stone
2020-09-22 19:22 ` Daniel Stone
2020-09-22 22:27 ` [Intel-gfx] ✗ Fi.CI.IGT: failure for " Patchwork
2020-09-23 8:17 ` [Intel-gfx] [PATCH] " Pekka Paalanen
2020-09-23 8:17 ` Pekka Paalanen
2020-09-23 8:17 ` Pekka Paalanen
2020-09-23 9:16 ` [Intel-gfx] " Daniel Vetter
2020-09-23 9:16 ` Daniel Vetter
2020-09-23 9:16 ` Daniel Vetter
2020-09-23 9:21 ` [Intel-gfx] " Daniel Vetter
2020-09-23 9:21 ` Daniel Vetter
2020-09-23 9:21 ` Daniel Vetter
2020-09-23 9:26 ` [Intel-gfx] " Daniel Vetter
2020-09-23 9:26 ` Daniel Vetter
2020-09-23 9:26 ` Daniel Vetter
2020-09-23 9:55 ` Pekka Paalanen [this message]
2020-09-23 9:55 ` Pekka Paalanen
2020-09-23 9:55 ` Pekka Paalanen
2020-09-23 10:31 ` [Intel-gfx] " Ville Syrjälä
2020-09-23 10:31 ` Ville Syrjälä
2020-09-23 10:37 ` [Intel-gfx] " Daniel Vetter
2020-09-23 10:37 ` Daniel Vetter
2020-09-23 10:37 ` Daniel Vetter
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=20200923125502.4735f720@eldfell \
--to=ppaalanen@gmail.com \
--cc=contact@emersion.fr \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=stable@vger.kernel.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.