[PATCH v4] drm/virtio: conditionally allocate virtio_gpu_fence
Dmitry Osipenko
dmitry.osipenko at collabora.com
Sun Jul 9 21:23:18 UTC 2023
08.07.2023 00:31, Gurchetan Singh пишет:
> 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 at chromium.org>
> ---
> v2: Fix indent (Dmitry)
> v3: Refactor drm fence event checks to avoid possible NULL deref (Dmitry)
> v4: More detailed commit message about addition drm fence event checks (Dmitry)
>
> drivers/gpu/drm/virtio/virtgpu_submit.c | 28 +++++++++++++------------
> 1 file changed, 15 insertions(+), 13 deletions(-)
Applied to misc-next
--
Best regards,
Dmitry
More information about the dri-devel
mailing list