From: Andi Shyti <andi.shyti@linux.intel.com>
To: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: intel-gfx@lists.freedesktop.org,
Lucas De Marchi <lucas.demarchi@intel.com>,
Matthew Auld <matthew.auld@intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915: add wait and lock to i915_vma_move_to_active
Date: Fri, 21 Oct 2022 17:51:42 +0200 [thread overview]
Message-ID: <Y1LADqViVzJAIMGe@ashyti-mobl2.lan> (raw)
In-Reply-To: <20221013133001.3639326-2-andrzej.hajda@intel.com>
Hi Andrzej,
(at first I r-b'ed this patch, but then I wanted to think on some
more "simplification" (if it really simplifies things). Please
read the review in patch 2 first )
> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> index 1cae24349a96fd..80e7fdd5d16427 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> @@ -565,10 +565,8 @@ static int make_obj_busy(struct drm_i915_gem_object *obj)
> goto err_unpin;
> }
>
> - err = i915_request_await_object(rq, vma->obj, true);
> - if (err == 0)
> - err = i915_vma_move_to_active(vma, rq,
> - EXEC_OBJECT_WRITE);
> + err = i915_vma_move_to_active(vma, rq,
> + EXEC_OBJECT_WRITE);
nit: don't need to break the line here.
>
> i915_request_add(rq);
> err_unpin:
[...]
> @@ -860,9 +854,7 @@ static int read_whitelisted_registers(struct intel_context *ce,
> return PTR_ERR(rq);
>
> i915_vma_lock(results);
> - err = i915_request_await_object(rq, results->obj, true);
> - if (err == 0)
> - err = i915_vma_move_to_active(results, rq, EXEC_OBJECT_WRITE);
> + err = i915_vma_move_to_active(results, rq, EXEC_OBJECT_WRITE);
> i915_vma_unlock(results);
> if (err)
> goto err_req;
> @@ -944,9 +936,7 @@ static int scrub_whitelisted_registers(struct intel_context *ce)
> }
>
> i915_vma_lock(batch);
> - err = i915_request_await_object(rq, batch->obj, false);
> - if (err == 0)
> - err = i915_vma_move_to_active(batch, rq, 0);
> + err = i915_vma_move_to_active(batch, rq, 0);
> i915_vma_unlock(batch);
The final risult would be:
i915_vma_lock();
i915_vma_move_to_active()
i915_vma_unlock();
and it's a pattern... as I suggested in patch 2, how about having
an:
i915_vma_move_to_active_unlocked()
and...
> if (err)
> goto err_request;
> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c b/drivers/gpu/drm/i915/gvt/scheduler.c
> index d6fe94cd0fdb61..b49098f045005e 100644
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@ -570,9 +570,8 @@ static int prepare_shadow_batch_buffer(struct intel_vgpu_workload *workload)
> if (gmadr_bytes == 8)
> bb->bb_start_cmd_va[2] = 0;
>
> - ret = i915_vma_move_to_active(bb->vma,
> - workload->req,
> - 0);
> + ret = _i915_vma_move_to_active(bb->vma, workload->req,
> + &workload->req->fence, 0);
> if (ret)
> goto err;
>
> diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
> index 15816df916c781..19138e99d2fd03 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -2015,9 +2015,7 @@ emit_oa_config(struct i915_perf_stream *stream,
> goto err_add_request;
> }
>
> - err = i915_request_await_object(rq, vma->obj, 0);
> - if (!err)
> - err = i915_vma_move_to_active(vma, rq, 0);
> + err = i915_vma_move_to_active(vma, rq, 0);
> if (err)
> goto err_add_request;
>
> diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
> index aecd9c64486b27..47ac5bd1ffcce6 100644
> --- a/drivers/gpu/drm/i915/i915_vma.h
> +++ b/drivers/gpu/drm/i915/i915_vma.h
> @@ -64,7 +64,11 @@ static inline int __must_check
> i915_vma_move_to_active(struct i915_vma *vma, struct i915_request *rq,
> unsigned int flags)
> {
> - return _i915_vma_move_to_active(vma, rq, &rq->fence, flags);
> + int err = i915_request_await_object(rq, vma->obj, flags & EXEC_OBJECT_WRITE);
> +
> + if (!err)
> + err = _i915_vma_move_to_active(vma, rq, &rq->fence, flags);
> + return err;
> }
... this i915_vma_move_to_active() now it's doing more than just
moving to active but it's also waiting on dma fences, shall we
call it i915_vma_move_to_active_async() or silimar? (I'm not good
at giving names).
The above would be i915_vma_move_to_active_async_unlocked(). Too
long? More complex?
We would have something like:
i915_vma_move_to_active() /* not used */
i915_vma_move_to_active_unlocked()
i915_vma_move_to_active_async()
i915_vma_move_to_active_async_unlocked()
Anyway as it is looks good, I didn't spot any error in the
conversion:
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Andi
[...]
next prev parent reply other threads:[~2022-10-21 15:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-13 13:29 [Intel-gfx] [PATCH 0/2] drm/i915: refactor 915_vma_move_to_active Andrzej Hajda
2022-10-13 13:30 ` [Intel-gfx] [PATCH 1/2] drm/i915: add wait and lock to i915_vma_move_to_active Andrzej Hajda
2022-10-13 14:00 ` Tvrtko Ursulin
2022-10-21 15:51 ` Andi Shyti [this message]
2022-10-24 13:45 ` Andrzej Hajda
2022-10-13 13:30 ` [Intel-gfx] [PATCH 2/2] drm/i915/selftests: add igt_vma_move_to_active_unlocked Andrzej Hajda
2022-10-21 15:39 ` Andi Shyti
2022-10-24 14:05 ` Andrzej Hajda
2022-10-24 15:08 ` Andi Shyti
2022-10-28 13:42 ` Andrzej Hajda
2022-10-13 15:06 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: refactor 915_vma_move_to_active Patchwork
2022-10-13 17:24 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
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=Y1LADqViVzJAIMGe@ashyti-mobl2.lan \
--to=andi.shyti@linux.intel.com \
--cc=andrzej.hajda@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=matthew.auld@intel.com \
--cc=rodrigo.vivi@intel.com \
/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