similar to: [PATCH] drm/virtio: do NOT reuse resource ids

Also update the comment with a reference to the virglrenderer fix. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_object.c | 44 ++++++++++++++----------- 1 file changed, 24 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c b/drivers/gpu/drm/virtio/virtgpu_object.c index e7e946035027..a73dae4e5029 100644 ---

0-based IDAs are more efficient than any other base. Convert the 1-based IDAs to be 0-based. Signed-off-by: Matthew Wilcox <willy at infradead.org> --- drivers/gpu/drm/virtio/virtgpu_kms.c | 3 ++- drivers/gpu/drm/virtio/virtgpu_vq.c | 7 +++++-- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c

Rework fencing workflow. Stop using ttm helpers, use the virtio_gpu_array_* helpers instead. Due to using the gem reservation object it is initialized and ready for use before calling ttm_bo_init. So we can simply use the standard fencing workflow and drop the tricky logic which checks whenever the command is in flight still. v6: rewrite most of the patch. Signed-off-by: Gerd Hoffmann

Rework fencing workflow. Stop using ttm helpers, use the virtio_gpu_array_* helpers instead. Due to using the gem reservation object it is initialized and ready for use before calling ttm_bo_init. So we can simply use the standard fencing workflow and drop the tricky logic which checks whenever the command is in flight still. v6: rewrite most of the patch. Signed-off-by: Gerd Hoffmann

Create virtio_gpu_object_params, use that to pass object parameters to virtio_gpu_object_create. Also drop unused "kernel" parameter (unused, always false). Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 15 ++++++++++----- drivers/gpu/drm/virtio/virtgpu_gem.c | 18 +++++++++++------- drivers/gpu/drm/virtio/virtgpu_ioctl.c |

I noticed you were using IDRs where you could be using the more efficient IDAs, then while fixing that I noticed the lack of error handling, and I decided to follow that up with an efficiency improvement. There's probably a v2 of this to follow because I couldn't figure out how to properly handle one of the error cases ... see the comment embedded in one of the patches. Matthew Wilcox

virtio-gpu basically needs a sg_table for the bo, to tell the host where the backing pages for the object are. So the gem shmem helpers are a perfect fit. Some drm_gem_object_funcs need thin wrappers to update the host state, but otherwise the helpers handle everything just fine. Once the fencing was sorted the switch was surprisingly easy and for the most part just removing the ttm code. v4:

virtio-gpu basically needs a sg_table for the bo, to tell the host where the backing pages for the object are. So the gem shmem helpers are a perfect fit. Some drm_gem_object_funcs need thin wrappers to update the host state, but otherwise the helpers handle everything just fine. Once the fencing was sorted the switch was surprisingly easy and for the most part just removing the ttm code.

virtio-gpu basically needs a sg_table for the bo, to tell the host where the backing pages for the object are. So the gem shmem helpers are a perfect fit. Some drm_gem_object_funcs need thin wrappers to update the host state, but otherwise the helpers handle everything just fine. Once the fencing was sorted the switch was surprisingly easy and for the most part just removing the ttm code. v5:

virtio-gpu basically needs a sg_table for the bo, to tell the host where the backing pages for the object are. So the gem shmem helpers are a perfect fit. Some drm_gem_object_funcs need thin wrappers to update the host state, but otherwise the helpers handle everything just fine. Once the fencing was sorted the switch was surprisingly easy and for the most part just removing the ttm code.

. On Wed, Jun 19, 2019 at 11:08 PM Gerd Hoffmann <kraxel at redhat.com> wrote: > > virtio-gpu basically needs a sg_table for the bo, to tell the host where > the backing pages for the object are. So the gem shmem helpers are a > perfect fit. Some drm_gem_object_funcs need thin wrappers to update the > host state, but otherwise the helpers handle everything just fine. >

Add new virtio_gpu_cleanup_object() helper function for object cleanup. Wire up callback function for resource unref, do cleanup from callback when we know the host stopped using the resource. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 4 +++- drivers/gpu/drm/virtio/virtgpu_object.c | 19 +++++++++++-----

On Wed, Feb 5, 2020 at 3:00 AM Gerd Hoffmann <kraxel at redhat.com> wrote: > > Add new virtio_gpu_cleanup_object() helper function for object cleanup. > Wire up callback function for resource unref, do cleanup from callback > when we know the host stopped using the resource. > > Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> > --- >

Add new virtio_gpu_cleanup_object() helper function for object cleanup. Wire up callback function for resource unref, do cleanup from callback when we know the host stopped using the resource. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 3 ++- drivers/gpu/drm/virtio/virtgpu_object.c | 19 ++++++++++----

Add new virtio_gpu_cleanup_object() helper function for object cleanup. Wire up callback function for resource unref, do cleanup from callback when we know the host stopped using the resource. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 3 ++- drivers/gpu/drm/virtio/virtgpu_object.c | 19 ++++++++++----

virtio-gpu basically needs a sg_table for the bo, to tell the host where the backing pages for the object are. So the gem shmem helpers are a perfect fit. Some drm_gem_object_funcs need thin wrappers to update the host state, but otherwise the helpers handle everything just fine. Once the fencing was sorted the switch was surprisingly easy and for the most part just removing the ttm code. v4:

virtio-gpu basically needs a sg_table for the bo, to tell the host where the backing pages for the object are. So the gem shmem helpers are a perfect fit. Some drm_gem_object_funcs need thin wrappers to update the host state, but otherwise the helpers handle everything just fine. Once the fencing was sorted the switch was surprisingly easy and for the most part just removing the ttm code. v4:

virtio-gpu basically needs a sg_table for the bo, to tell the host where the backing pages for the object are. So the gem shmem helpers are a perfect fit. Some drm_gem_object_funcs need thin wrappers to update the host state, but otherwise the helpers handle everything just fine. Once the fencing was sorted the switch was surprisingly easy and for the most part just removing the ttm code. v4:

virtio-gpu uses cached mappings, set shmem->caching accordingly. Reported-by: Gurchetan Singh <gurchetansingh at chromium.org> Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_object.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c b/drivers/gpu/drm/virtio/virtgpu_object.c index

On Wed, Sep 26, 2018 at 09:00:31AM -0700, Matthew Wilcox wrote: > @@ -59,6 +59,7 @@ static int virtio_gpu_context_create(struct virtio_gpu_device *vgdev, > > if (handle < 0) > return handle; > + handle++; > virtio_gpu_cmd_context_create(vgdev, handle, nlen, name); > return handle; > } Uh. This line is missing. - int handle =