From: Daniel Vetter <daniel@ffwll.ch>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: David Airlie <airlied@linux.ie>,
open list <linux-kernel@vger.kernel.org>,
dri-devel@lists.freedesktop.org,
"open list:VIRTIO GPU DRIVER"
<virtualization@lists.linux-foundation.org>
Subject: Re: [PATCH v2 07/12] drm/virtio: rework virtio_gpu_execbuffer_ioctl fencing
Date: Tue, 18 Jun 2019 16:16:04 +0200 [thread overview]
Message-ID: <20190618141604.GC12905@phenom.ffwll.local> (raw)
In-Reply-To: <20190618135821.8644-8-kraxel@redhat.com>
On Tue, Jun 18, 2019 at 03:58:15PM +0200, Gerd Hoffmann wrote:
> Use gem reservation helpers and direct reservation_object_* calls
> instead of ttm.
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
> drivers/gpu/drm/virtio/virtgpu_ioctl.c | 36 ++++++++++++--------------
> 1 file changed, 17 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> index 5cffd2e54c04..6db6a6e92dde 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> @@ -107,12 +107,11 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device *dev, void *data,
> struct virtio_gpu_fpriv *vfpriv = drm_file->driver_priv;
> struct drm_gem_object *gobj;
> struct virtio_gpu_fence *out_fence;
> - struct virtio_gpu_object *qobj;
> int ret;
> uint32_t *bo_handles = NULL;
> void __user *user_bo_handles = NULL;
> struct list_head validate_list;
> - struct ttm_validate_buffer *buflist = NULL;
> + struct drm_gem_object **buflist = NULL;
> int i;
> struct ww_acquire_ctx ticket;
> struct sync_file *sync_file;
> @@ -157,12 +156,11 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device *dev, void *data,
>
> INIT_LIST_HEAD(&validate_list);
> if (exbuf->num_bo_handles) {
> -
> bo_handles = kvmalloc_array(exbuf->num_bo_handles,
> - sizeof(uint32_t), GFP_KERNEL);
> + sizeof(uint32_t), GFP_KERNEL);
> buflist = kvmalloc_array(exbuf->num_bo_handles,
> - sizeof(struct ttm_validate_buffer),
> - GFP_KERNEL | __GFP_ZERO);
> + sizeof(struct drm_gem_object*),
> + GFP_KERNEL | __GFP_ZERO);
> if (!bo_handles || !buflist) {
> ret = -ENOMEM;
> goto out_unused_fd;
> @@ -181,19 +179,15 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device *dev, void *data,
> ret = -ENOENT;
> goto out_unused_fd;
> }
> -
> - qobj = gem_to_virtio_gpu_obj(gobj);
> - buflist[i].bo = &qobj->tbo;
> -
> - list_add(&buflist[i].head, &validate_list);
> + buflist[i] = gobj;
I didn't bother looking, but I guess there's some room for a
array-of-gem-id to gem_bo-pointers helper function? Would only make sense
if we can share it with panfrost/v3d maybe.
> }
> kvfree(bo_handles);
> bo_handles = NULL;
> }
>
> - ret = virtio_gpu_object_list_validate(&ticket, &validate_list);
> + ret = drm_gem_lock_reservations(buflist, exbuf->num_bo_handles, &ticket);
> if (ret)
> - goto out_free;
> + goto out_unused_fd;
>
> buf = memdup_user(u64_to_user_ptr(exbuf->command), exbuf->size);
> if (IS_ERR(buf)) {
> @@ -222,21 +216,25 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device *dev, void *data,
> virtio_gpu_cmd_submit(vgdev, buf, exbuf->size,
> vfpriv->ctx_id, out_fence);
>
> - ttm_eu_fence_buffer_objects(&ticket, &validate_list, &out_fence->f);
> + for (i = 0; i < exbuf->num_bo_handles; i++)
> + reservation_object_add_excl_fence(buflist[i]->resv, &out_fence->f);
Helper to unref an array of gem bo? Probably also needed by other drivers.
> + drm_gem_unlock_reservations(buflist, exbuf->num_bo_handles, &ticket);
>
> - /* fence the command bo */
> - virtio_gpu_unref_list(&validate_list);
> + for (i = 0; i < exbuf->num_bo_handles; i++)
> + if (buflist[i])
> + drm_gem_object_put_unlocked(buflist[i]);
I am left wondering who's holding references onto these buffers now? How
do you make sure they don't disappear untimely?
I think atm it's ttm making sure of that, but if you drop that completely
there needs to be something else.
> kvfree(buflist);
> return 0;
>
> out_memdup:
> kfree(buf);
> out_unresv:
> - ttm_eu_backoff_reservation(&ticket, &validate_list);
> -out_free:
> - virtio_gpu_unref_list(&validate_list);
> + drm_gem_unlock_reservations(buflist, exbuf->num_bo_handles, &ticket);
> out_unused_fd:
> kvfree(bo_handles);
> + for (i = 0; i < exbuf->num_bo_handles; i++)
> + if (buflist && buflist[i])
> + drm_gem_object_put_unlocked(buflist[i]);
> kvfree(buflist);
>
> if (out_fence_fd >= 0)
Patch itself looks correct, just put down my thoughts while reviewing it.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> --
> 2.18.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: dri-devel@lists.freedesktop.org, David Airlie <airlied@linux.ie>,
Daniel Vetter <daniel@ffwll.ch>,
"open list:VIRTIO GPU DRIVER"
<virtualization@lists.linux-foundation.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 07/12] drm/virtio: rework virtio_gpu_execbuffer_ioctl fencing
Date: Tue, 18 Jun 2019 16:16:04 +0200 [thread overview]
Message-ID: <20190618141604.GC12905@phenom.ffwll.local> (raw)
In-Reply-To: <20190618135821.8644-8-kraxel@redhat.com>
On Tue, Jun 18, 2019 at 03:58:15PM +0200, Gerd Hoffmann wrote:
> Use gem reservation helpers and direct reservation_object_* calls
> instead of ttm.
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
> drivers/gpu/drm/virtio/virtgpu_ioctl.c | 36 ++++++++++++--------------
> 1 file changed, 17 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> index 5cffd2e54c04..6db6a6e92dde 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> @@ -107,12 +107,11 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device *dev, void *data,
> struct virtio_gpu_fpriv *vfpriv = drm_file->driver_priv;
> struct drm_gem_object *gobj;
> struct virtio_gpu_fence *out_fence;
> - struct virtio_gpu_object *qobj;
> int ret;
> uint32_t *bo_handles = NULL;
> void __user *user_bo_handles = NULL;
> struct list_head validate_list;
> - struct ttm_validate_buffer *buflist = NULL;
> + struct drm_gem_object **buflist = NULL;
> int i;
> struct ww_acquire_ctx ticket;
> struct sync_file *sync_file;
> @@ -157,12 +156,11 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device *dev, void *data,
>
> INIT_LIST_HEAD(&validate_list);
> if (exbuf->num_bo_handles) {
> -
> bo_handles = kvmalloc_array(exbuf->num_bo_handles,
> - sizeof(uint32_t), GFP_KERNEL);
> + sizeof(uint32_t), GFP_KERNEL);
> buflist = kvmalloc_array(exbuf->num_bo_handles,
> - sizeof(struct ttm_validate_buffer),
> - GFP_KERNEL | __GFP_ZERO);
> + sizeof(struct drm_gem_object*),
> + GFP_KERNEL | __GFP_ZERO);
> if (!bo_handles || !buflist) {
> ret = -ENOMEM;
> goto out_unused_fd;
> @@ -181,19 +179,15 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device *dev, void *data,
> ret = -ENOENT;
> goto out_unused_fd;
> }
> -
> - qobj = gem_to_virtio_gpu_obj(gobj);
> - buflist[i].bo = &qobj->tbo;
> -
> - list_add(&buflist[i].head, &validate_list);
> + buflist[i] = gobj;
I didn't bother looking, but I guess there's some room for a
array-of-gem-id to gem_bo-pointers helper function? Would only make sense
if we can share it with panfrost/v3d maybe.
> }
> kvfree(bo_handles);
> bo_handles = NULL;
> }
>
> - ret = virtio_gpu_object_list_validate(&ticket, &validate_list);
> + ret = drm_gem_lock_reservations(buflist, exbuf->num_bo_handles, &ticket);
> if (ret)
> - goto out_free;
> + goto out_unused_fd;
>
> buf = memdup_user(u64_to_user_ptr(exbuf->command), exbuf->size);
> if (IS_ERR(buf)) {
> @@ -222,21 +216,25 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device *dev, void *data,
> virtio_gpu_cmd_submit(vgdev, buf, exbuf->size,
> vfpriv->ctx_id, out_fence);
>
> - ttm_eu_fence_buffer_objects(&ticket, &validate_list, &out_fence->f);
> + for (i = 0; i < exbuf->num_bo_handles; i++)
> + reservation_object_add_excl_fence(buflist[i]->resv, &out_fence->f);
Helper to unref an array of gem bo? Probably also needed by other drivers.
> + drm_gem_unlock_reservations(buflist, exbuf->num_bo_handles, &ticket);
>
> - /* fence the command bo */
> - virtio_gpu_unref_list(&validate_list);
> + for (i = 0; i < exbuf->num_bo_handles; i++)
> + if (buflist[i])
> + drm_gem_object_put_unlocked(buflist[i]);
I am left wondering who's holding references onto these buffers now? How
do you make sure they don't disappear untimely?
I think atm it's ttm making sure of that, but if you drop that completely
there needs to be something else.
> kvfree(buflist);
> return 0;
>
> out_memdup:
> kfree(buf);
> out_unresv:
> - ttm_eu_backoff_reservation(&ticket, &validate_list);
> -out_free:
> - virtio_gpu_unref_list(&validate_list);
> + drm_gem_unlock_reservations(buflist, exbuf->num_bo_handles, &ticket);
> out_unused_fd:
> kvfree(bo_handles);
> + for (i = 0; i < exbuf->num_bo_handles; i++)
> + if (buflist && buflist[i])
> + drm_gem_object_put_unlocked(buflist[i]);
> kvfree(buflist);
>
> if (out_fence_fd >= 0)
Patch itself looks correct, just put down my thoughts while reviewing it.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> --
> 2.18.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2019-06-18 14:16 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-18 13:58 [PATCH v2 00/12] drm/virtio: switch from ttm to gem shmem helpers Gerd Hoffmann
2019-06-18 13:58 ` [PATCH v2 01/12] drm/virtio: pass gem reservation object to ttm init Gerd Hoffmann
2019-06-18 13:58 ` Gerd Hoffmann
2019-06-18 13:58 ` Gerd Hoffmann
2019-06-18 13:58 ` [PATCH v2 02/12] drm/virtio: switch virtio_gpu_wait_ioctl() to gem helper Gerd Hoffmann
2019-06-18 13:58 ` Gerd Hoffmann
2019-06-18 14:07 ` Daniel Vetter
2019-06-18 14:07 ` Daniel Vetter
2019-06-18 13:58 ` Gerd Hoffmann
2019-06-18 13:58 ` [PATCH v2 03/12] drm/virtio: simplify cursor updates Gerd Hoffmann
2019-06-18 13:58 ` Gerd Hoffmann
2019-06-18 13:58 ` Gerd Hoffmann
2019-06-18 13:58 ` [PATCH v2 04/12] drm/virtio: remove virtio_gpu_object_wait Gerd Hoffmann
2019-06-18 13:58 ` Gerd Hoffmann
2019-06-18 13:58 ` Gerd Hoffmann
2019-06-18 13:58 ` [PATCH v2 05/12] drm/virtio: drop no_wait argument from virtio_gpu_object_reserve Gerd Hoffmann
2019-06-18 13:58 ` Gerd Hoffmann
2019-06-18 13:58 ` Gerd Hoffmann
2019-06-18 13:58 ` [PATCH v2 06/12] drm/virtio: remove ttm calls from in virtio_gpu_object_{reserve, unreserve} Gerd Hoffmann
2019-06-18 13:58 ` Gerd Hoffmann
2019-06-18 13:58 ` [PATCH v2 06/12] drm/virtio: remove ttm calls from in virtio_gpu_object_{reserve,unreserve} Gerd Hoffmann
2019-06-18 14:09 ` Daniel Vetter
2019-06-18 14:09 ` Daniel Vetter
2019-06-18 14:09 ` Daniel Vetter
2019-06-18 13:58 ` [PATCH v2 07/12] drm/virtio: rework virtio_gpu_execbuffer_ioctl fencing Gerd Hoffmann
2019-06-18 13:58 ` Gerd Hoffmann
2019-06-18 14:16 ` Daniel Vetter
2019-06-18 14:16 ` Daniel Vetter [this message]
2019-06-18 14:16 ` Daniel Vetter
2019-06-18 14:23 ` Daniel Vetter
2019-06-18 14:23 ` Daniel Vetter
2019-06-18 13:58 ` Gerd Hoffmann
2019-06-18 13:58 ` [PATCH v2 08/12] drm/virtio: rework virtio_gpu_object_create fencing Gerd Hoffmann
2019-06-18 13:58 ` Gerd Hoffmann
2019-06-18 13:58 ` Gerd Hoffmann
2019-06-18 14:24 ` Daniel Vetter
2019-06-18 14:24 ` Daniel Vetter
2019-06-18 13:58 ` [PATCH v2 09/12] drm/virtio: drop virtio_gpu_object_list_validate/virtio_gpu_unref_list Gerd Hoffmann
2019-06-18 13:58 ` Gerd Hoffmann
2019-06-18 13:58 ` Gerd Hoffmann
2019-06-18 13:58 ` [PATCH v2 10/12] drm/virtio: switch from ttm to gem shmem helpers Gerd Hoffmann
2019-06-18 13:58 ` Gerd Hoffmann
2019-06-18 13:58 ` Gerd Hoffmann
2019-06-18 13:58 ` [PATCH v2 11/12] drm/virtio: rework virtio_gpu_object_create fencing even more Gerd Hoffmann
2019-06-18 13:58 ` Gerd Hoffmann
2019-06-18 13:58 ` Gerd Hoffmann
2019-06-18 13:58 ` [PATCH v2 12/12] drm/virtio: remove virtio_gpu_alloc_object Gerd Hoffmann
2019-06-18 13:58 ` Gerd Hoffmann
2019-06-18 13:58 ` Gerd Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190618141604.GC12905@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=kraxel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.