kernel.git/drivers/gpu/drm/virtio/virtgpu_fence.c, 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: rework virtio_fence_signaled

2020-12-02T10:48:14Z

virtio_gpu_fence_event_process sets the last_fence_id and subsequently calls dma_fence_signal_locked(..). dma_fence_signal_locked(..) sets DMA_FENCE_FLAG_SIGNALED_BIT, which is actually checked before &dma_fence_ops.(*signaled) is called. The check for last_fence_id is therefore a bit redundant, and it will not be sufficient to check the last_fence_id for multiple synchronization timelines. Remove it. v3: add r-b tags Signed-off-by: Gurchetan Singh Reviewed-by: Anthoine Bourgeois Link: http://patchwork.freedesktop.org/patch/msgid/20201201021623.619-2-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann

drm/virtio: virtio_{blah} --> virtio_gpu_{blah}

2020-12-02T10:48:14Z

virtio_gpu typically uses the prefix virtio_gpu, but there are a few places where the virtio prefix is used. Modify this for consistency. v3: add r-b tags Signed-off-by: Gurchetan Singh Reviewed-by: Anthoine Bourgeois Link: http://patchwork.freedesktop.org/patch/msgid/20201201021623.619-1-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: move to_virtio_fence inside virtgpu_fence

2019-12-19T06:13:46Z

That's the only file that uses it. Signed-off-by: Gurchetan Singh Link: http://patchwork.freedesktop.org/patch/msgid/20191219005733.18960-5-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann

drm/virtio: static-ify virtio_fence_signaled

2019-12-19T06:13:45Z

Not used anywhere else. Signed-off-by: Gurchetan Singh Link: http://patchwork.freedesktop.org/patch/msgid/20191219005733.18960-1-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann

drm/virtio: add fence sanity check

2019-09-04T04:54:12Z

Make sure we don't leak half-initialized fences outside the driver. Signed-off-by: Gerd Hoffmann Reviewed-by: Chia-I Wu Link: http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-19-kraxel@redhat.com

drm/virtgpu: drop use of drmP.h

2019-07-15T16:11:31Z

Drop use of the deprecated drmP.h header file. Fix fallout by adding missing include files. Signed-off-by: Sam Ravnborg Acked-by: Gerd Hoffmann Acked-by: Emil Velikov Cc: David Airlie Cc: Daniel Vetter Cc: virtualization@lists.linux-foundation.org Link: https://patchwork.freedesktop.org/patch/msgid/20190630061922.7254-28-sam@ravnborg.org

drm/virtio: Remove redundant return type

2019-05-06T13:36:23Z

virtio_gpu_fence_emit() always returns 0, since it has no error paths. Consequently no calls for virtio_gpu_fence_emit() use the return value, and it can be removed. Signed-off-by: Robert Foss Reviewed-by: Chia-I Wu Link: http://patchwork.freedesktop.org/patch/msgid/20190506091034.30289-1-robert.foss@collabora.com Suggested-by: Emil Velikov Reviewed-by: Chia-I Wu Signed-off-by: Gerd Hoffmann