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: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190618135821.8644-1-kraxel@redhat.com>
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 ` [PATCH v2 02/12] drm/virtio: switch virtio_gpu_wait_ioctl() to gem helper Gerd Hoffmann
2019-06-18 14:07 ` Daniel Vetter
2019-06-18 13:58 ` [PATCH v2 03/12] drm/virtio: simplify cursor updates 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 ` [PATCH v2 05/12] drm/virtio: drop no_wait argument from virtio_gpu_object_reserve 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 13:58 ` [PATCH v2 07/12] drm/virtio: rework virtio_gpu_execbuffer_ioctl fencing Gerd Hoffmann
2019-06-18 14:16 ` Daniel Vetter [this message]
2019-06-18 14:23 ` Daniel Vetter
2019-06-18 13:58 ` [PATCH v2 08/12] drm/virtio: rework virtio_gpu_object_create fencing Gerd Hoffmann
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 ` [PATCH v2 10/12] drm/virtio: switch from ttm to gem shmem helpers 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 ` [PATCH v2 12/12] drm/virtio: remove virtio_gpu_alloc_object 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox