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:
- bo_handles, to be used with VIRTGPU_WAIT
- out_fence_fd, to be used with dma_fence apis
- a ring_idx provided with VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK
- DRM event API
- 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-gurchetan... (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