From: Greg KH <gregkh@linuxfoundation.org>
To: Alyssa Ross <hi@alyssa.is>
Cc: stable@vger.kernel.org,
Gurchetan Singh <gurchetansingh@chromium.org>,
Dmitry Osipenko <dmitry.osipenko@collabora.com>
Subject: Re: [PATCH 6.1.y,6.4.y] drm/virtio: Conditionally allocate virtio_gpu_fence
Date: Wed, 13 Sep 2023 10:21:35 +0200 [thread overview]
Message-ID: <2023091322-silk-drone-fd5b@gregkh> (raw)
In-Reply-To: <20230912123534.893716-1-hi@alyssa.is>
On Tue, Sep 12, 2023 at 12:35:34PM +0000, Alyssa Ross wrote:
> From: Gurchetan Singh <gurchetansingh@chromium.org>
>
> We don't want to create a fence for every command submission. It's
> only necessary when userspace provides a waitable token for submission.
> This could be:
>
> 1) bo_handles, to be used with VIRTGPU_WAIT
> 2) out_fence_fd, to be used with dma_fence apis
> 3) a ring_idx provided with VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK
> + DRM event API
> 4) syncobjs in the future
>
> The use case for just submitting a command to the host, and expecting
> no response. For example, gfxstream has GFXSTREAM_CONTEXT_PING that
> just wakes up the host side worker threads. There's also
> CROSS_DOMAIN_CMD_SEND which just sends data to the Wayland server.
>
> This prevents the need to signal the automatically created
> virtio_gpu_fence.
>
> In addition, VIRTGPU_EXECBUF_RING_IDX is checked when creating a
> DRM event object. VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK is
> already defined in terms of per-context rings. It was theoretically
> possible to create a DRM event on the global timeline (ring_idx == 0),
> if the context enabled DRM event polling. However, that wouldn't
> work and userspace (Sommelier). Explicitly disallow it for
> clarity.
>
> Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> # edited coding style
> Link: https://patchwork.freedesktop.org/patch/msgid/20230707213124.494-1-gurchetansingh@chromium.org
> (cherry picked from commit 70d1ace56db6c79d39dbe9c0d5244452b67e2fde)
> Signed-off-by: Alyssa Ross <hi@alyssa.is>
> ---
> drivers/gpu/drm/virtio/virtgpu_ioctl.c | 30 +++++++++++++++-----------
> 1 file changed, 18 insertions(+), 12 deletions(-)
Both patches applied, thanks.
greg k-h
prev parent reply other threads:[~2023-09-13 8:21 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-12 12:35 [PATCH 6.1.y,6.4.y] drm/virtio: Conditionally allocate virtio_gpu_fence Alyssa Ross
2023-09-13 8:21 ` Greg KH [this message]
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=2023091322-silk-drone-fd5b@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=dmitry.osipenko@collabora.com \
--cc=gurchetansingh@chromium.org \
--cc=hi@alyssa.is \
--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.