From: Pekka Paalanen <ppaalanen@gmail.com>
To: Rob Clark <robdclark@gmail.com>
Cc: "Rob Clark" <robdclark@chromium.org>,
"Tvrtko Ursulin" <tvrtko.ursulin@intel.com>,
"Gustavo Padovan" <gustavo@padovan.org>,
"Michel Dänzer" <michel@daenzer.net>,
"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
"open list" <linux-kernel@vger.kernel.org>,
dri-devel@lists.freedesktop.org,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"moderated list:DMA BUFFER SHARING FRAMEWORK"
<linaro-mm-sig@lists.linaro.org>,
"Luben Tuikov" <luben.tuikov@amd.com>,
"Christian König" <ckoenig.leichtzumerken@gmail.com>,
"Alex Deucher" <alexander.deucher@amd.com>,
freedreno@lists.freedesktop.org,
"Christian König" <christian.koenig@amd.com>,
"open list:SYNC FILE FRAMEWORK" <linux-media@vger.kernel.org>
Subject: Re: [PATCH v4 06/14] dma-buf/sync_file: Support (E)POLLPRI
Date: Fri, 24 Feb 2023 11:26:30 +0200 [thread overview]
Message-ID: <20230224112630.313d7b76@eldfell> (raw)
In-Reply-To: <CAF6AEGuE89kuKTjjzwW1xMppcVw-M4-hcrtifed-mvsCA=cshQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2064 bytes --]
On Thu, 23 Feb 2023 10:51:48 -0800
Rob Clark <robdclark@gmail.com> wrote:
> On Thu, Feb 23, 2023 at 1:38 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> >
> > On Wed, 22 Feb 2023 07:37:26 -0800
> > Rob Clark <robdclark@gmail.com> wrote:
> >
> > > On Wed, Feb 22, 2023 at 1:49 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
...
> > > > On another matter, if the application uses SET_DEADLINE with one
> > > > timestamp, and the compositor uses SET_DEADLINE on the same thing with
> > > > another timestamp, what should happen?
> > >
> > > The expectation is that many deadline hints can be set on a fence.
> > > The fence signaller should track the soonest deadline.
> >
> > You need to document that as UAPI, since it is observable to userspace.
> > It would be bad if drivers or subsystems would differ in behaviour.
> >
>
> It is in the end a hint. It is about giving the driver more
> information so that it can make better choices. But the driver is
> even free to ignore it. So maybe "expectation" is too strong of a
> word. Rather, any other behavior doesn't really make sense. But it
> could end up being dictated by how the hw and/or fw works.
It will stop being a hint once it has been implemented and used in the
wild long enough. The kernel userspace regression rules make sure of
that.
See the topic of implementing triple-buffering in Mutter in order to
put more work to the GPU in order to have the GPU ramp up clocks in
order to not miss rendering deadlines. I don't think that patch set has
landed in Mutter upstream, but I hear distributions in downstream are
already carrying it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1383
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441
Granted, GPU clocks are just one side of that story it seems, and
triple-buffering may have other benefits.
If SET_DEADLINE would fix that problem without triple-buffering, it is
definitely userspace observable, expected and eventually required
behaviour.
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: Rob Clark <robdclark@gmail.com>
Cc: "Luben Tuikov" <luben.tuikov@amd.com>,
"Rob Clark" <robdclark@chromium.org>,
"Gustavo Padovan" <gustavo@padovan.org>,
"Tvrtko Ursulin" <tvrtko.ursulin@intel.com>,
"Christian König" <ckoenig.leichtzumerken@gmail.com>,
"Michel Dänzer" <michel@daenzer.net>,
"open list" <linux-kernel@vger.kernel.org>,
dri-devel@lists.freedesktop.org,
"Christian König" <christian.koenig@amd.com>,
"moderated list:DMA BUFFER SHARING FRAMEWORK"
<linaro-mm-sig@lists.linaro.org>,
"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
"Alex Deucher" <alexander.deucher@amd.com>,
freedreno@lists.freedesktop.org,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"open list:SYNC FILE FRAMEWORK" <linux-media@vger.kernel.org>
Subject: Re: [PATCH v4 06/14] dma-buf/sync_file: Support (E)POLLPRI
Date: Fri, 24 Feb 2023 11:26:30 +0200 [thread overview]
Message-ID: <20230224112630.313d7b76@eldfell> (raw)
In-Reply-To: <CAF6AEGuE89kuKTjjzwW1xMppcVw-M4-hcrtifed-mvsCA=cshQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2064 bytes --]
On Thu, 23 Feb 2023 10:51:48 -0800
Rob Clark <robdclark@gmail.com> wrote:
> On Thu, Feb 23, 2023 at 1:38 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> >
> > On Wed, 22 Feb 2023 07:37:26 -0800
> > Rob Clark <robdclark@gmail.com> wrote:
> >
> > > On Wed, Feb 22, 2023 at 1:49 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
...
> > > > On another matter, if the application uses SET_DEADLINE with one
> > > > timestamp, and the compositor uses SET_DEADLINE on the same thing with
> > > > another timestamp, what should happen?
> > >
> > > The expectation is that many deadline hints can be set on a fence.
> > > The fence signaller should track the soonest deadline.
> >
> > You need to document that as UAPI, since it is observable to userspace.
> > It would be bad if drivers or subsystems would differ in behaviour.
> >
>
> It is in the end a hint. It is about giving the driver more
> information so that it can make better choices. But the driver is
> even free to ignore it. So maybe "expectation" is too strong of a
> word. Rather, any other behavior doesn't really make sense. But it
> could end up being dictated by how the hw and/or fw works.
It will stop being a hint once it has been implemented and used in the
wild long enough. The kernel userspace regression rules make sure of
that.
See the topic of implementing triple-buffering in Mutter in order to
put more work to the GPU in order to have the GPU ramp up clocks in
order to not miss rendering deadlines. I don't think that patch set has
landed in Mutter upstream, but I hear distributions in downstream are
already carrying it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1383
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441
Granted, GPU clocks are just one side of that story it seems, and
triple-buffering may have other benefits.
If SET_DEADLINE would fix that problem without triple-buffering, it is
definitely userspace observable, expected and eventually required
behaviour.
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-02-24 9:26 UTC|newest]
Thread overview: 185+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-18 21:15 [Intel-gfx] [PATCH v4 00/14] dma-fence: Deadline awareness Rob Clark
2023-02-18 21:15 ` Rob Clark
2023-02-18 21:15 ` Rob Clark
2023-02-18 21:15 ` [PATCH v4 01/14] dma-buf/dma-fence: Add deadline awareness Rob Clark
2023-02-18 21:15 ` Rob Clark
2023-02-22 10:23 ` Tvrtko Ursulin
2023-02-22 10:23 ` Tvrtko Ursulin
2023-02-22 15:28 ` Christian König
2023-02-22 15:28 ` Christian König
2023-02-22 17:04 ` Tvrtko Ursulin
2023-02-22 17:04 ` Tvrtko Ursulin
2023-02-22 17:16 ` Rob Clark
2023-02-22 17:16 ` Rob Clark
2023-02-22 17:33 ` Tvrtko Ursulin
2023-02-22 17:33 ` Tvrtko Ursulin
2023-02-22 18:57 ` Rob Clark
2023-02-22 18:57 ` Rob Clark
2023-02-22 11:01 ` Luben Tuikov
2023-02-22 11:01 ` Luben Tuikov
2023-02-18 21:15 ` [PATCH v4 02/14] dma-buf/fence-array: Add fence deadline support Rob Clark
2023-02-18 21:15 ` Rob Clark
2023-02-18 21:15 ` [PATCH v4 03/14] dma-buf/fence-chain: " Rob Clark
2023-02-18 21:15 ` Rob Clark
2023-02-22 10:27 ` Tvrtko Ursulin
2023-02-22 10:27 ` Tvrtko Ursulin
2023-02-22 15:55 ` Rob Clark
2023-02-22 15:55 ` Rob Clark
2023-02-18 21:15 ` [PATCH v4 04/14] dma-buf/dma-resv: Add a way to set fence deadline Rob Clark
2023-02-18 21:15 ` Rob Clark
2023-02-20 8:16 ` Christian König
2023-02-20 8:16 ` Christian König
2023-02-18 21:15 ` [PATCH v4 05/14] dma-buf/sync_file: Add SET_DEADLINE ioctl Rob Clark
2023-02-18 21:15 ` Rob Clark
2023-02-20 8:27 ` Christian König
2023-02-20 8:27 ` Christian König
2023-02-20 16:09 ` Rob Clark
2023-02-20 16:09 ` Rob Clark
2023-02-21 8:41 ` Pekka Paalanen
2023-02-21 8:41 ` Pekka Paalanen
2023-02-23 9:19 ` Christian König
2023-02-23 9:19 ` Christian König
2023-02-20 8:48 ` Pekka Paalanen
2023-02-20 8:48 ` Pekka Paalanen
2023-02-18 21:15 ` [PATCH v4 06/14] dma-buf/sync_file: Support (E)POLLPRI Rob Clark
2023-02-18 21:15 ` Rob Clark
2023-02-20 8:31 ` Christian König
2023-02-20 8:31 ` Christian König
2023-02-21 8:38 ` Pekka Paalanen
2023-02-21 8:38 ` Pekka Paalanen
2023-02-20 8:53 ` Pekka Paalanen
2023-02-20 8:53 ` Pekka Paalanen
2023-02-20 16:14 ` Rob Clark
2023-02-20 16:14 ` Rob Clark
2023-02-21 8:37 ` Pekka Paalanen
2023-02-21 8:37 ` Pekka Paalanen
2023-02-21 16:01 ` Sebastian Wick
2023-02-21 16:01 ` Sebastian Wick
2023-02-21 17:55 ` Rob Clark
2023-02-21 17:55 ` Rob Clark
2023-02-21 16:48 ` Luben Tuikov
2023-02-21 16:48 ` Luben Tuikov
2023-02-21 17:53 ` Rob Clark
2023-02-21 17:53 ` Rob Clark
2023-02-22 9:49 ` Pekka Paalanen
2023-02-22 9:49 ` Pekka Paalanen
2023-02-22 10:26 ` Luben Tuikov
2023-02-22 10:26 ` Luben Tuikov
2023-02-22 15:37 ` Rob Clark
2023-02-22 15:37 ` Rob Clark
2023-02-23 9:38 ` Pekka Paalanen
2023-02-23 9:38 ` Pekka Paalanen
2023-02-23 18:51 ` Rob Clark
2023-02-23 18:51 ` Rob Clark
2023-02-24 9:26 ` Pekka Paalanen [this message]
2023-02-24 9:26 ` Pekka Paalanen
2023-02-24 9:41 ` Tvrtko Ursulin
2023-02-24 9:41 ` Tvrtko Ursulin
2023-02-24 10:24 ` Pekka Paalanen
2023-02-24 10:24 ` Pekka Paalanen
2023-02-24 10:50 ` Tvrtko Ursulin
2023-02-24 10:50 ` Tvrtko Ursulin
2023-02-24 11:00 ` Pekka Paalanen
2023-02-24 11:00 ` Pekka Paalanen
2023-02-24 11:37 ` Tvrtko Ursulin
2023-02-24 11:37 ` Tvrtko Ursulin
2023-02-24 15:26 ` Luben Tuikov
2023-02-24 15:26 ` Luben Tuikov
2023-02-24 17:59 ` Rob Clark
2023-02-24 17:59 ` Rob Clark
2023-02-27 21:35 ` Rodrigo Vivi
2023-02-27 21:35 ` Rodrigo Vivi
2023-02-27 22:20 ` Rob Clark
2023-02-27 22:20 ` Rob Clark
2023-02-27 22:44 ` Sebastian Wick
2023-02-27 22:44 ` Sebastian Wick
2023-02-27 23:48 ` Rob Clark
2023-02-27 23:48 ` Rob Clark
2023-02-28 14:30 ` Sebastian Wick
2023-02-28 14:30 ` Sebastian Wick
2023-02-28 22:52 ` Rob Clark
2023-02-28 22:52 ` Rob Clark
2023-03-01 15:31 ` Sebastian Wick
2023-03-01 15:31 ` Sebastian Wick
2023-03-01 16:02 ` Rob Clark
2023-03-01 16:02 ` Rob Clark
2023-03-01 15:45 ` Rodrigo Vivi
2023-03-01 15:45 ` Rodrigo Vivi
2023-02-24 16:59 ` Rob Clark
2023-02-24 16:59 ` Rob Clark
2023-02-24 19:44 ` Rob Clark
2023-02-24 19:44 ` Rob Clark
2023-02-27 9:34 ` Pekka Paalanen
2023-02-27 9:34 ` Pekka Paalanen
2023-02-27 18:43 ` Rob Clark
2023-02-27 18:43 ` Rob Clark
2023-02-18 21:15 ` [PATCH v4 07/14] dma-buf/sw_sync: Add fence deadline support Rob Clark
2023-02-18 21:15 ` Rob Clark
2023-02-20 8:29 ` Christian König
2023-02-20 8:29 ` Christian König
2023-02-18 21:15 ` [PATCH v4 08/14] drm/scheduler: " Rob Clark
2023-02-18 21:15 ` Rob Clark
2023-02-21 19:40 ` Luben Tuikov
2023-02-21 19:40 ` Luben Tuikov
2023-02-18 21:15 ` [PATCH v4 09/14] drm/syncobj: Add deadline support for syncobj waits Rob Clark
2023-02-18 21:15 ` Rob Clark
2023-02-19 16:09 ` Rob Clark
2023-02-19 16:09 ` Rob Clark
2023-02-20 9:05 ` Pekka Paalanen
2023-02-20 9:05 ` Pekka Paalanen
2023-02-20 16:20 ` Rob Clark
2023-02-20 16:20 ` Rob Clark
2023-02-24 9:51 ` Tvrtko Ursulin
2023-02-24 9:51 ` Tvrtko Ursulin
2023-02-18 21:15 ` [PATCH v4 10/14] drm/vblank: Add helper to get next vblank time Rob Clark
2023-02-18 21:15 ` Rob Clark
2023-02-20 9:08 ` Pekka Paalanen
2023-02-20 9:08 ` Pekka Paalanen
2023-02-20 15:55 ` Rob Clark
2023-02-20 15:55 ` Rob Clark
2023-02-21 8:45 ` Pekka Paalanen
2023-02-21 8:45 ` Pekka Paalanen
2023-02-21 13:01 ` Ville Syrjälä
2023-02-21 13:01 ` Ville Syrjälä
2023-02-21 13:11 ` Pekka Paalanen
2023-02-21 13:11 ` Pekka Paalanen
2023-02-21 13:42 ` Ville Syrjälä
2023-02-21 13:42 ` Ville Syrjälä
2023-02-21 17:50 ` Rob Clark
2023-02-21 17:50 ` Rob Clark
2023-02-22 9:57 ` Pekka Paalanen
2023-02-22 9:57 ` Pekka Paalanen
2023-02-22 15:44 ` Rob Clark
2023-02-22 15:44 ` Rob Clark
2023-02-22 15:55 ` Ville Syrjälä
2023-02-22 15:55 ` Ville Syrjälä
2023-02-21 19:54 ` Rob Clark
2023-02-21 19:54 ` Rob Clark
2023-02-21 21:39 ` Ville Syrjälä
2023-02-21 21:39 ` Ville Syrjälä
2023-02-21 21:48 ` Ville Syrjälä
2023-02-21 21:48 ` Ville Syrjälä
2023-02-21 22:28 ` [Freedreno] " Rob Clark
2023-02-21 22:46 ` Ville Syrjälä
2023-02-21 23:20 ` Rob Clark
2023-02-21 23:25 ` Rob Clark
2023-02-22 10:37 ` Luben Tuikov
2023-02-22 10:37 ` Luben Tuikov
2023-02-22 15:48 ` Rob Clark
2023-02-22 15:48 ` Rob Clark
2023-02-18 21:15 ` [PATCH v4 11/14] drm/atomic-helper: Set fence deadline for vblank Rob Clark
2023-02-18 21:15 ` Rob Clark
2023-02-22 10:46 ` Luben Tuikov
2023-02-22 10:46 ` Luben Tuikov
2023-02-22 15:50 ` Rob Clark
2023-02-22 15:50 ` Rob Clark
2023-02-18 21:15 ` [PATCH v4 12/14] drm/msm: Add deadline based boost support Rob Clark
2023-02-18 21:15 ` Rob Clark
2023-02-18 21:15 ` [PATCH v4 13/14] drm/msm: Add wait-boost support Rob Clark
2023-02-18 21:15 ` Rob Clark
2023-02-18 21:15 ` [Intel-gfx] [PATCH v4 14/14] drm/i915: Add deadline based boost support Rob Clark
2023-02-18 21:15 ` Rob Clark
2023-02-18 21:15 ` Rob Clark
2023-02-20 15:46 ` [Intel-gfx] " Tvrtko Ursulin
2023-02-20 15:46 ` Tvrtko Ursulin
2023-02-20 15:46 ` Tvrtko Ursulin
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=20230224112630.313d7b76@eldfell \
--to=ppaalanen@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=christian.koenig@amd.com \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=gustavo@padovan.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=luben.tuikov@amd.com \
--cc=michel@daenzer.net \
--cc=robdclark@chromium.org \
--cc=robdclark@gmail.com \
--cc=rodrigo.vivi@intel.com \
--cc=sumit.semwal@linaro.org \
--cc=tvrtko.ursulin@intel.com \
/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.