From: Pekka Paalanen <ppaalanen@gmail.com>
To: "Kasireddy, Vivek" <vivek.kasireddy@intel.com>
Cc: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Subject: Re: [RFC v1 3/6] drm: Add a capability flag to support additional flip completion signalling
Date: Fri, 15 Oct 2021 10:50:14 +0300 [thread overview]
Message-ID: <20211015105014.0375d196@eldfell> (raw)
In-Reply-To: <6a78da70ffab4b35b0e78a1e6570cb59@intel.com>
[-- Attachment #1: Type: text/plain, Size: 4753 bytes --]
On Fri, 15 Oct 2021 03:37:01 +0000
"Kasireddy, Vivek" <vivek.kasireddy@intel.com> wrote:
> Hi Pekka,
> Thank you for reviewing this patch.
>
Hi Vivek!
> > On Mon, 13 Sep 2021 16:35:26 -0700
> > Vivek Kasireddy <vivek.kasireddy@intel.com> wrote:
> >
> > > If a driver supports this capability, it means that there would be an
> > > additional signalling mechanism for a page flip completion in addition
> > > to out_fence or DRM_MODE_PAGE_FLIP_EVENT.
> > >
> > > This capability may only be relevant for Virtual KMS drivers and is currently
> > > used only by virtio-gpu. Also, it can provide a potential solution for:
> > > https://gitlab.freedesktop.org/wayland/weston/-/issues/514
> > >
> > > Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
> > > ---
> > > drivers/gpu/drm/drm_ioctl.c | 3 +++
> > > include/drm/drm_mode_config.h | 8 ++++++++
> > > include/uapi/drm/drm.h | 1 +
> > > 3 files changed, 12 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> > > index 8b8744dcf691..8a420844f8bc 100644
> > > --- a/drivers/gpu/drm/drm_ioctl.c
> > > +++ b/drivers/gpu/drm/drm_ioctl.c
> > > @@ -302,6 +302,9 @@ static int drm_getcap(struct drm_device *dev, void *data, struct
> > drm_file *file_
> > > case DRM_CAP_CRTC_IN_VBLANK_EVENT:
> > > req->value = 1;
> > > break;
> > > + case DRM_CAP_RELEASE_FENCE:
> > > + req->value = dev->mode_config.release_fence;
> > > + break;
> >
> > Hi Vivek,
> >
> > is this actually necessary?
> >
> > I would think that userspace figures out the existence of the release
> > fence capability by seeing that the KMS property "RELEASE_FENCE_PTR"
> > either exists or not.
> [Vivek] Yeah, that makes sense. However, in order for the userspace to not see
> this property, we'd have to prevent drm core from exposing it; which means we
> need to check dev->mode_config.release_fence before attaching the property
> to the crtc.
Kernel implementation details, I don't bother with those personally. ;-)
Sounds right.
> >
> > However, would we not need a client cap instead?
> >
> > If a KMS driver knows that userspace is aware of "RELEASE_FENCE_PTR"
> > and will use it when necessary, then the KMS driver can send the
> > pageflip completion without waiting for the host OS to signal the old
> > buffer as free for re-use.
> [Vivek] Right, the KMS driver can just look at whether the release_fence was
> added by the userspace (in the atomic commit) to determine whether it needs
> to wait for the old fb.
You could do it that way, but is it a good idea? I'm not sure.
> > If the KMS driver does not know that userspace can handle pageflip
> > completing "too early", then it has no choice but to wait until the old
> > buffer is really free before signalling pageflip completion.
> >
> > Wouldn't that make sense?
> [Vivek] Yes; DRM_CAP_RELEASE_FENCE may not be necessary to
> implement the behavior you suggest which makes sense.
>
> >
> >
> > Otherwise, this proposal sounds fine to me.
> [Vivek] Did you get a chance to review the Weston MR:
> https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/668
>
> Could you please take a look?
Unfortunately I cannot promise any timely feedback on that, I try to
concentrate on CM&HDR. However, I'm not the only Weston reviewer, I
hope.
Thanks,
pq
>
> Thanks,
> Vivek
>
> >
> >
> > Thanks,
> > pq
> >
> >
> > > default:
> > > return -EINVAL;
> > > }
> > > diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> > > index 12b964540069..944bebf359d7 100644
> > > --- a/include/drm/drm_mode_config.h
> > > +++ b/include/drm/drm_mode_config.h
> > > @@ -935,6 +935,14 @@ struct drm_mode_config {
> > > */
> > > bool normalize_zpos;
> > >
> > > + /**
> > > + * @release_fence:
> > > + *
> > > + * If this option is set, it means there would be an additional signalling
> > > + * mechanism for a page flip completion.
> > > + */
> > > + bool release_fence;
> > > +
> > > /**
> > > * @modifiers_property: Plane property to list support modifier/format
> > > * combination.
> > > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> > > index 3b810b53ba8b..8b8985f65581 100644
> > > --- a/include/uapi/drm/drm.h
> > > +++ b/include/uapi/drm/drm.h
> > > @@ -767,6 +767,7 @@ struct drm_gem_open {
> > > * Documentation/gpu/drm-mm.rst, section "DRM Sync Objects".
> > > */
> > > #define DRM_CAP_SYNCOBJ_TIMELINE 0x14
> > > +#define DRM_CAP_RELEASE_FENCE 0x15
> > >
> > > /* DRM_IOCTL_GET_CAP ioctl argument type */
> > > struct drm_get_cap {
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-10-15 7:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-13 23:35 [RFC v1 0/6] drm: Add support for DRM_CAP_RELEASE_FENCE capability Vivek Kasireddy
2021-09-13 23:35 ` [RFC v1 1/6] drm/atomic: Move out_fence creation/setup into a separate function Vivek Kasireddy
2021-09-13 23:35 ` [RFC v1 2/6] drm/atomic: Add support for release_fence and its associated property Vivek Kasireddy
2021-09-13 23:35 ` [RFC v1 3/6] drm: Add a capability flag to support additional flip completion signalling Vivek Kasireddy
2021-10-14 9:44 ` Pekka Paalanen
2021-10-15 3:37 ` Kasireddy, Vivek
2021-10-15 7:50 ` Pekka Paalanen [this message]
2021-10-18 0:18 ` Kasireddy, Vivek
2021-09-13 23:35 ` [RFC v1 4/6] drm/virtio: Probe and implement VIRTIO_GPU_F_RELEASE_FENCE feature Vivek Kasireddy
2021-09-15 5:16 ` Gerd Hoffmann
2021-09-16 2:33 ` Kasireddy, Vivek
2021-09-13 23:35 ` [RFC v1 5/6] drm/virtio: Prepare set_scanout_blob to accept a fence Vivek Kasireddy
2021-09-13 23:35 ` [RFC v1 6/6] drm/virtio: Add a fence to set_scanout_blob Vivek Kasireddy
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=20211015105014.0375d196@eldfell \
--to=ppaalanen@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=vivek.kasireddy@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.