All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pekka Paalanen <ppaalanen@gmail.com>
To: Vivek Kasireddy <vivek.kasireddy@intel.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [RFC v1 3/6] drm: Add a capability flag to support additional flip completion signalling
Date: Thu, 14 Oct 2021 12:44:02 +0300	[thread overview]
Message-ID: <20211014124402.46f95ebc@eldfell> (raw)
In-Reply-To: <20210913233529.3194401-4-vivek.kasireddy@intel.com>

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

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.

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.

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?


Otherwise, this proposal sounds fine to me.


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-14  9:44 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 [this message]
2021-10-15  3:37     ` Kasireddy, Vivek
2021-10-15  7:50       ` Pekka Paalanen
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=20211014124402.46f95ebc@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.