70d1ace56d
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 |
||
|---|---|---|
| .. | ||
| Kconfig | ||
| Makefile | ||
| virtgpu_debugfs.c | ||
| virtgpu_display.c | ||
| virtgpu_drv.c | ||
| virtgpu_drv.h | ||
| virtgpu_fence.c | ||
| virtgpu_gem.c | ||
| virtgpu_ioctl.c | ||
| virtgpu_kms.c | ||
| virtgpu_object.c | ||
| virtgpu_plane.c | ||
| virtgpu_prime.c | ||
| virtgpu_submit.c | ||
| virtgpu_trace.h | ||
| virtgpu_trace_points.c | ||
| virtgpu_vq.c | ||
| virtgpu_vram.c | ||