From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v6 13/25] drm/i915: Remove the identical implementations of request space reservation
Date: Wed, 27 Apr 2016 13:27:37 +0300 [thread overview]
Message-ID: <1461752857.3986.25.camel@linux.intel.com> (raw)
In-Reply-To: <1461701180-895-14-git-send-email-chris@chris-wilson.co.uk>
On ti, 2016-04-26 at 21:06 +0100, Chris Wilson wrote:
> Now that we share intel_ring_begin(), reserving space for the tail of
> the request is identical between legacy/execlists and so the tautology
> can be removed. In the process, we move the reserved space tracking
> from the ringbuffer on to the request. This is to enable us to reorder
> the reserved space allocation in the next patch.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Some comments below.
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> ---
> drivers/gpu/drm/i915/i915_drv.h | 3 +++
> drivers/gpu/drm/i915/i915_gem.c | 21 ++++++++++------
> drivers/gpu/drm/i915/intel_lrc.c | 15 -----------
> drivers/gpu/drm/i915/intel_ringbuffer.c | 44 +++------------------------------
> drivers/gpu/drm/i915/intel_ringbuffer.h | 17 -------------
> 5 files changed, 19 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 444a8ea0c5c4..831da9f43324 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2278,6 +2278,9 @@ struct drm_i915_gem_request {
> /** Position in the ringbuffer of the end of the whole request */
> u32 tail;
>
> + /** Preallocate space in the ringbuffer for the emitting the request */
> + u32 reserved_space;
> +
> /**
> * Context and ring buffer related to this request
> * Contexts are refcounted, so when this request is associated with a
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 71135c3ce44e..0e27484bd28a 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2573,6 +2573,7 @@ void __i915_add_request(struct drm_i915_gem_request *request,
> struct drm_i915_private *dev_priv;
> struct intel_ringbuffer *ringbuf;
> u32 request_start;
> + u32 reserved_tail;
> int ret;
>
> if (WARN_ON(request == NULL))
> @@ -2587,9 +2588,10 @@ void __i915_add_request(struct drm_i915_gem_request *request,
> * should already have been reserved in the ring buffer. Let the ring
> * know that it is time to use that space up.
> */
> - intel_ring_reserved_space_use(ringbuf);
> -
> request_start = intel_ring_get_tail(ringbuf);
> + reserved_tail = request->reserved_space;
> + request->reserved_space = 0;
> +
> /*
> * Emit any outstanding flushes - execbuf can fail to emit the flush
> * after having emitted the batchbuffer command. Hence we need to fix
> @@ -2653,7 +2655,13 @@ void __i915_add_request(struct drm_i915_gem_request *request,
> intel_mark_busy(dev_priv->dev);
>
> /* Sanity check that the reserved size was large enough. */
> - intel_ring_reserved_space_end(ringbuf);
> + ret = intel_ring_get_tail(ringbuf) - request_start;
> + if (ret < 0)
> + ret += ringbuf->size;
> + WARN_ONCE(ret > reserved_tail,
> + "Not enough space reserved (%d bytes) "
> + "for adding the request (%d bytes)\n",
> + reserved_tail, ret);
Not sure if I'd rather prefer this to stay in an enclosed function and
not spill ringbuf stuff in the function.
> }
>
> static bool i915_context_is_banned(struct drm_i915_private *dev_priv,
> @@ -2774,17 +2782,14 @@ __i915_gem_request_alloc(struct intel_engine_cs *engine,
> * to be redone if the request is not actually submitted straight
> * away, e.g. because a GPU scheduler has deferred it.
> */
> - if (i915.enable_execlists)
> - ret = intel_logical_ring_reserve_space(req);
> - else
> - ret = intel_ring_reserve_space(req);
> + req->reserved_space = MIN_SPACE_FOR_ADD_REQUEST;
> + ret = intel_ring_begin(req, 0);
> if (ret) {
> /*
> * At this point, the request is fully allocated even if not
> * fully prepared. Thus it can be cleaned up using the proper
> * free code.
> */
> - intel_ring_reserved_space_cancel(req->ringbuf);
You could append this to the above comment that the resrved space will
be released along it.
> i915_gem_request_unreference(req);
> return ret;
> }
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
> index ba87c94928e7..910044cf143e 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -772,21 +772,6 @@ intel_logical_ring_advance_and_submit(struct drm_i915_gem_request *request)
> return 0;
> }
>
> -int intel_logical_ring_reserve_space(struct drm_i915_gem_request *request)
> -{
> - /*
> - * The first call merely notes the reserve request and is common for
> - * all back ends. The subsequent localised _begin() call actually
> - * ensures that the reservation is available. Without the begin, if
> - * the request creator immediately submitted the request without
> - * adding any commands to it then there might not actually be
> - * sufficient room for the submission commands.
> - */
> - intel_ring_reserved_space_reserve(request->ringbuf, MIN_SPACE_FOR_ADD_REQUEST);
> -
> - return intel_ring_begin(request, 0);
> -}
> -
> /**
> * execlists_submission() - submit a batchbuffer for execution, Execlists style
> * @dev: DRM device.
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 1d3d2ea3e9bc..ba5946b9fa06 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -2336,44 +2336,6 @@ int intel_ring_alloc_request_extras(struct drm_i915_gem_request *request)
> return 0;
> }
>
> -int intel_ring_reserve_space(struct drm_i915_gem_request *request)
> -{
> - /*
> - * The first call merely notes the reserve request and is common for
> - * all back ends. The subsequent localised _begin() call actually
> - * ensures that the reservation is available. Without the begin, if
> - * the request creator immediately submitted the request without
> - * adding any commands to it then there might not actually be
> - * sufficient room for the submission commands.
> - */
> - intel_ring_reserved_space_reserve(request->ringbuf, MIN_SPACE_FOR_ADD_REQUEST);
> -
> - return intel_ring_begin(request, 0);
> -}
> -
> -void intel_ring_reserved_space_reserve(struct intel_ringbuffer *ringbuf, int size)
> -{
> - GEM_BUG_ON(ringbuf->reserved_size);
> - ringbuf->reserved_size = size;
> -}
> -
> -void intel_ring_reserved_space_cancel(struct intel_ringbuffer *ringbuf)
> -{
> - GEM_BUG_ON(!ringbuf->reserved_size);
> - ringbuf->reserved_size = 0;
> -}
> -
> -void intel_ring_reserved_space_use(struct intel_ringbuffer *ringbuf)
> -{
> - GEM_BUG_ON(!ringbuf->reserved_size);
> - ringbuf->reserved_size = 0;
> -}
> -
> -void intel_ring_reserved_space_end(struct intel_ringbuffer *ringbuf)
> -{
> - GEM_BUG_ON(ringbuf->reserved_size);
> -}
> -
> static int wait_for_space(struct drm_i915_gem_request *req, int bytes)
> {
> struct intel_ringbuffer *ringbuf = req->ringbuf;
> @@ -2385,7 +2347,7 @@ static int wait_for_space(struct drm_i915_gem_request *req, int bytes)
> return 0;
>
> /* The whole point of reserving space is to not wait! */
> - GEM_BUG_ON(!ringbuf->reserved_size);
> + GEM_BUG_ON(!req->reserved_space);
>
> list_for_each_entry(target, &engine->request_list, list) {
> unsigned space;
> @@ -2420,7 +2382,7 @@ int intel_ring_begin(struct drm_i915_gem_request *req, int num_dwords)
> int total_bytes, wait_bytes;
> bool need_wrap = false;
>
> - total_bytes = bytes + ringbuf->reserved_size;
> + total_bytes = bytes + req->reserved_space;
>
> if (unlikely(bytes > remain_usable)) {
> /*
> @@ -2436,7 +2398,7 @@ int intel_ring_begin(struct drm_i915_gem_request *req, int num_dwords)
> * and only need to effectively wait for the reserved
> * size space from the start of ringbuffer.
> */
> - wait_bytes = remain_actual + ringbuf->reserved_size;
> + wait_bytes = remain_actual + req->reserved_space;
> } else
> /* No wrapping required, just waiting. */
> wait_bytes = total_bytes;
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h b/drivers/gpu/drm/i915/intel_ringbuffer.h
> index 201e7752d765..038914ccc6fd 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> @@ -107,7 +107,6 @@ struct intel_ringbuffer {
> int space;
> int size;
> int effective_size;
> - int reserved_size;
>
> /** We track the position of the requests in the ring buffer, and
> * when each is retired we increment last_retired_head as the GPU
> @@ -491,20 +490,4 @@ static inline u32 intel_ring_get_tail(struct intel_ringbuffer *ringbuf)
> */
> #define MIN_SPACE_FOR_ADD_REQUEST 160
>
> -/*
> - * Reserve space in the ring to guarantee that the i915_add_request() call
> - * will always have sufficient room to do its stuff. The request creation
> - * code calls this automatically.
> - */
> -void intel_ring_reserved_space_reserve(struct intel_ringbuffer *ringbuf, int size);
> -/* Cancel the reservation, e.g. because the request is being discarded. */
> -void intel_ring_reserved_space_cancel(struct intel_ringbuffer *ringbuf);
> -/* Use the reserved space - for use by i915_add_request() only. */
> -void intel_ring_reserved_space_use(struct intel_ringbuffer *ringbuf);
> -/* Finish with the reserved space - for use by i915_add_request() only. */
> -void intel_ring_reserved_space_end(struct intel_ringbuffer *ringbuf);
> -
> -/* Legacy ringbuffer specific portion of reservation code: */
> -int intel_ring_reserve_space(struct drm_i915_gem_request *request);
> -
> #endif /* _INTEL_RINGBUFFER_H_ */
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-04-27 10:26 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-26 20:05 Premature unpinning, finally? Chris Wilson
2016-04-26 20:05 ` [PATCH v6 01/25] drm/i915/fbdev: Call intel_unpin_fb_obj() on release Chris Wilson
2016-04-27 12:45 ` Tvrtko Ursulin
2016-04-26 20:05 ` [PATCH v6 02/25] drm/i915/overlay: Replace i915_gem_obj_ggtt_offset() with the known flip_addr Chris Wilson
[not found] ` <1461701180-895-1-git-send-email-chris-Y6uKTt2uX1cEflXRtASbqLVCufUGDwFn@public.gmane.org>
2016-04-26 20:05 ` [PATCH v6 03/25] io-mapping: Specify mapping size for io_mapping_map_wc() Chris Wilson
2016-04-26 20:05 ` [PATCH v6 04/25] drm/i915: Introduce i915_vm_to_ggtt() Chris Wilson
2016-04-26 20:06 ` [PATCH v6 05/25] drm/i915: Move ioremap_wc tracking onto VMA Chris Wilson
2016-04-26 20:06 ` [PATCH v6 06/25] drm/i915: Use i915_vma_pin_iomap on the ringbuffer object Chris Wilson
2016-04-26 20:06 ` [PATCH v6 07/25] drm/i915: Mark the current context as lost on suspend Chris Wilson
2016-04-26 20:06 ` [PATCH v6 08/25] drm/i915: L3 cache remapping is part of context switching Chris Wilson
2016-04-26 20:06 ` [PATCH v6 09/25] drm/i915: Consolidate L3 remapping LRI Chris Wilson
2016-04-26 20:06 ` [PATCH v6 10/25] drm/i915: Remove early l3-remap Chris Wilson
2016-04-26 20:06 ` [PATCH v6 11/25] drm/i915: Rearrange switch_context to load the aliasing ppgtt on first use Chris Wilson
2016-04-26 20:06 ` [PATCH v6 12/25] drm/i915: Unify intel_ring_begin() Chris Wilson
2016-04-27 9:21 ` Joonas Lahtinen
2016-04-27 9:37 ` Chris Wilson
2016-04-27 10:54 ` Joonas Lahtinen
2016-04-26 20:06 ` [PATCH v6 13/25] drm/i915: Remove the identical implementations of request space reservation Chris Wilson
2016-04-27 10:27 ` Joonas Lahtinen [this message]
2016-04-26 20:06 ` [PATCH v6 14/25] drm/i915: Manually unwind after a failed request allocation Chris Wilson
2016-04-27 10:48 ` Joonas Lahtinen
2016-04-27 10:59 ` Chris Wilson
2016-04-27 12:51 ` Tvrtko Ursulin
2016-04-27 12:58 ` Chris Wilson
2016-04-27 13:03 ` Tvrtko Ursulin
2016-04-26 20:06 ` [PATCH v6 15/25] drm/i915: Preallocate enough space for the average request Chris Wilson
2016-04-27 13:15 ` Tvrtko Ursulin
2016-04-27 13:26 ` Chris Wilson
2016-04-26 20:06 ` [PATCH v6 16/25] drm/i915: Update execlists context descriptor format commentary Chris Wilson
2016-04-27 13:22 ` Tvrtko Ursulin
2016-04-26 20:06 ` [PATCH v6 17/25] drm/i915: Assign every HW context a unique ID Chris Wilson
2016-04-26 20:06 ` [PATCH v6 18/25] drm/i915: Replace the pinned context address with its " Chris Wilson
2016-04-26 20:06 ` [PATCH v6 19/25] drm/i915: Refactor execlists default context pinning Chris Wilson
2016-04-26 20:06 ` [PATCH v6 20/25] drm/i915: Move the magical deferred context allocation into the request Chris Wilson
2016-04-26 20:06 ` [PATCH v6 21/25] drm/i915: Move releasing of the GEM request from free to retire/cancel Chris Wilson
2016-04-26 20:06 ` [PATCH v6 22/25] drm/i915: Track the previous pinned context inside the request Chris Wilson
2016-04-26 20:06 ` [PATCH v6 23/25] drm/i915: Store LRC hardware id in " Chris Wilson
2016-04-26 20:06 ` [PATCH v6 24/25] drm/i915: Stop tracking execlists retired requests Chris Wilson
2016-04-26 20:06 ` [PATCH v6 25/25] drm/i915: Unify GPU resets upon shutdown Chris Wilson
2016-04-27 7:24 ` ✗ Fi.CI.BAT: failure for series starting with [v6,01/25] drm/i915/fbdev: Call intel_unpin_fb_obj() on release 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=1461752857.3986.25.camel@linux.intel.com \
--to=joonas.lahtinen@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.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