kernel.git/drivers/gpu/drm/virtio/virtgpu_drv.h, branch linux-5.14.y

drm/virtio: consider dma-fence context when signaling

2020-12-02T10:48:14Z

This an incremental refactor towards multiple dma-fence contexts in virtio-gpu. Since all fences are still allocated using &virtio_gpu_fence_driver.context, nothing should break and every processed fence will be signaled. The overall idea is every 3D context can allocate a number of dma-fence contexts. Each dma-fence context refers to it's own timeline. For example, consider the following case where virgl submits commands to the GPU (fence ids 1, 3) and does a metadata query with the CPU (fence id 5). In a different process, gfxstream submits commands to the GPU (fence ids 2, 4). fence_id (&dma_fence.seqno) | 1 2 3 4 5 ----------------------------------|----------- fence_ctx 0 (virgl gpu) | 1 3 fence_ctx 1 (virgl metadata query)| 5 fence_ctx 2 (gfxstream gpu) | 2 4 With multiple fence contexts, we can wait for the metadata query to finish without waiting for the virgl gpu to finish. virgl gpu does not have to wait for gfxstream gpu. The fence id still is the monotonically increasing sequence number, but it's only revelant to the specific dma-fence context. To fully enable this feature, we'll need to: - have each 3d context allocate a number of fence contexts. Not too hard with explicit context initialization on the horizon. - have guest userspace specify fence context when performing ioctls. - tag each fence emitted to the host with the fence context information. virtio_gpu_ctrl_hdr has padding + flags available, so that should be easy. This change goes in the direction specified above, by: - looking up the virtgpu_fence given a fence_id - signalling all prior fences in a given context - signalling current fence v2: fix grammar in comment v3: add r-b tags Reviewed-by: Anthoine Bourgeois Signed-off-by: Gurchetan Singh Link: http://patchwork.freedesktop.org/patch/msgid/20201201021623.619-3-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann

drm/virtio: rename sync_seq and last_seq

2020-11-20T09:44:41Z

To be clearer about our intentions to associate sequence numbers and fence IDs, let's rename these variables. Signed-off-by: Gurchetan Singh Reviewed-by: Anthoine Bourgeois Link: http://patchwork.freedesktop.org/patch/msgid/20201119010809.528-5-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann

drm/virtio: use fence_id when processing fences

2020-11-20T09:44:41Z

Currently, the fence ID, which can be used to identify a virtgpu fence, is the same as the fence sequence number. Let's use the fence_id name to clearly signal this. Signed-off-by: Gurchetan Singh Reviewed-by: Anthoine Bourgeois Link: http://patchwork.freedesktop.org/patch/msgid/20201119010809.528-4-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann

drm/virtio: fix a file name comment reference

2020-11-20T09:44:41Z

Easier to find where declarations are implemented. Signed-off-by: Anthoine Bourgeois Link: http://patchwork.freedesktop.org/patch/msgid/20201119010809.528-2-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann

drm/virtio: implement blob resources: resource create blob ioctl

2020-09-29T09:23:51Z

Implement resource create blob as specified. Signed-off-by: Gerd Hoffmann Acked-by: Tomeu Vizoso Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-18-gurchetansingh@chromium.org Co-developed-by: Gurchetan Singh Signed-off-by: Gurchetan Singh

drm/virtio: implement blob resources: fix stride discrepancy

2020-09-29T09:23:47Z

The old transfer ioctls may work on blob resources, and there is no TRANSFER_BLOB hypercall now for simplicity. The guest may have a image view on the blob resources such that the stride is not equal to width * bytes_per_pixel. For host-only blobs, we can repurpose the transfer ioctls to synchronize caches as well. For guest-only blobs, these operations are undefined for now so leave them out. Also, with seamless Wayland integration between guest/host looking increasingly attractive, it also makes sense to keep track of one value for stride. Signed-off-by: Gurchetan Singh Acked-by: Tomeu Vizoso Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-16-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann

drm/virtio: implement blob resources: refactor UUID code somewhat

2020-09-29T09:23:45Z

For upcoming blob resources, userspace can specify that the resource will be used for cross-device sharing. This is mainly for exportable blobs that will only shared with the virtgpu display but not across devices. Signed-off-by: Gurchetan Singh Acked-by: Tomeu Vizoso Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-15-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann

drm/virtio: implement blob resources: hypercall interface

2020-09-29T09:23:40Z

This implements the blob hypercall interface. Signed-off-by: Gurchetan Singh Acked-by: Tomeu Vizoso Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-13-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann

drm/virtio: implement blob resources: implement vram object

2020-09-29T09:23:33Z

A virtio-gpu vram object is based on range-based allocation. No guest shmemfs backing, so we call drm_gem_private_object_init. This is for host memory without any guest backing (atleast initially). Signed-off-by: Gerd Hoffmann Acked-by: Tomeu Vizoso Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-12-gurchetansingh@chromium.org Co-developed-by: Gurchetan Singh Signed-off-by: Gurchetan Singh

drm/virtio: implement blob resources: add new fields to internal structs

2020-09-29T09:23:31Z

Useful for upcoming blob resources. Signed-off-by: Gurchetan Singh Acked-by: Tomeu Vizoso Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-11-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann