dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
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 --]

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox