linux-dev/drivers/gpu/drm/virtio/virtgpu_drv.h, branch linus/master

drm/virtgpu api: define a dummy fence signaled event

2021-11-29T10:46:32Z

The current virtgpu implementation of poll(..) drops events when VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK is enabled (otherwise it's like a normal DRM driver). This is because paravirtualized userspaces receives responses in a buffer of type BLOB_MEM_GUEST, not by read(..). To be in line with other DRM drivers and avoid specialized behavior, it is possible to define a dummy event for virtgpu. Paravirtualized userspace will now have to call read(..) on the DRM fd to receive the dummy event. Fixes: b10790434cf2 ("drm/virtgpu api: create context init feature") Reported-by: Daniel Vetter Signed-off-by: Gurchetan Singh Reviewed-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20211122232210.602-2-gurchetansingh@google.com Signed-off-by: Gerd Hoffmann

drm/virtio: implement context init: add virtio_gpu_fence_event

2021-09-29T07:22:31Z

Similar to DRM_VMW_EVENT_FENCE_SIGNALED. Sends a pollable event to the DRM file descriptor when a fence on a specific ring is signaled. One difference is the event is not exposed via the UAPI -- this is because host responses are on a shared memory buffer of type BLOB_MEM_GUEST [this is the common way to receive responses with virtgpu]. As such, there is no context specific read(..) implementation either -- just a poll(..) implementation. Signed-off-by: Gurchetan Singh Acked-by: Nicholas Verne Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-12-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann

drm/virtio: implement context init: handle VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK

2021-09-29T07:22:31Z

For the Sommelier guest Wayland proxy, it's desirable for the DRM fd to be pollable in response to an host compositor event. This can also be used by the 3D driver to poll events on a CPU timeline. This enables the DRM fd associated with a particular 3D context to be polled independent of KMS events. The parameter VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK specifies the pollable rings. Signed-off-by: Gurchetan Singh Acked-by: Nicholas Verne Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-11-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann

drm/virtio: implement context init: allocate an array of fence contexts

2021-09-29T07:22:31Z

We don't want fences from different 3D contexts (virgl, gfxstream, venus) to be on the same timeline. With explicit context creation, we can specify the number of ring each context wants. Execbuffer can specify which ring to use. Signed-off-by: Gurchetan Singh Acked-by: Lingfeng Yang Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-10-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann

drm/virtio: implement context init: plumb {base_fence_ctx, ring_idx} to virtio_gpu_fence_alloc

2021-09-29T07:22:30Z

These were defined in the previous commit. We'll need these parameters when allocating a dma_fence. The use case for this is multiple synchronizations timelines. The maximum number of timelines per 3D instance will be 32. Usually, only 2 are needed -- one for CPU commands, and another for GPU commands. As such, we'll need to specify these parameters when allocating a dma_fence. vgdev->fence_drv.context is the "default" fence context for 2D mode and old userspace. Signed-off-by: Gurchetan Singh Acked-by: Lingfeng Yang Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-8-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann

drm/virtio: implement context init: track {ring_idx, emit_fence_info} in virtio_gpu_fence

2021-09-29T07:22:30Z

Each fence should be associated with a [fence ID, fence_context, seqno]. The seqno number is just the fence id. To get the fence context, we add the ring_idx to the 3D context's base_fence_ctx. The ring_idx is between 0 and 31, inclusive. Each 3D context will have it's own base_fence_ctx. The ring_idx will be emitted to host userspace, when emit_fence_info is true. Signed-off-by: Gurchetan Singh Acked-by: Lingfeng Yang Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-7-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann

drm/virtio: implement context init: support init ioctl

2021-09-29T07:22:30Z

This implements the context initialization ioctl. A list of params is passed in by userspace, and kernel driver validates them. The only currently supported param is VIRTGPU_CONTEXT_PARAM_CAPSET_ID. If the context has already been initialized, -EEXIST is returned. This happens after Linux userspace does dumb_create + followed by opening the Mesa virgl driver with the same virtgpu instance. However, for most applications, 3D contexts will be explicitly initialized when the feature is available. Signed-off-by: Anthoine Bourgeois Acked-by: Lingfeng Yang Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-6-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann

drm/virtio: implement context init: probe for feature

2021-09-29T07:22:30Z

Let's probe for VIRTIO_GPU_F_CONTEXT_INIT. Create a new DRM_INFO(..) line since the current one is getting too long. Signed-off-by: Anthoine Bourgeois Acked-by: Lingfeng Yang Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-5-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann

drm/virtio: implement context init: track valid capabilities in a mask

2021-09-29T07:22:30Z

The valid capability IDs are between 1 to 63, and defined in the virtio gpu spec. This is used for error checking the subsequent patches. We're currently only using 2 capability IDs, so this should be plenty for the immediate future. Signed-off-by: Gurchetan Singh Acked-by: Lingfeng Yang Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-4-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann

drm/virtio: support mapping exported vram

2021-08-16T12:09:40Z

Implement virtgpu specific map_dma_buf callback to support mapping exported vram object dma-bufs. The dma-buf callback is used directly, as vram objects don't have backing pages and thus can't implement the drm_gem_object_funcs.get_sg_table callback. Signed-off-by: David Stevens Link: http://patchwork.freedesktop.org/patch/msgid/20210813005441.608293-1-stevensd@chromium.org Signed-off-by: Gerd Hoffmann