From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: John.C.Harrison@Intel.com
Cc: Intel-GFX@lists.freedesktop.org
Subject: Re: [RFC 10/44] drm/i915: Prepare retire_requests to handle out-of-order seqnos
Date: Wed, 2 Jul 2014 11:11:36 -0700 [thread overview]
Message-ID: <20140702111136.54065e21@jbarnes-desktop> (raw)
In-Reply-To: <1403803475-16337-11-git-send-email-John.C.Harrison@Intel.com>
On Thu, 26 Jun 2014 18:24:01 +0100
John.C.Harrison@Intel.com wrote:
> From: John Harrison <John.C.Harrison@Intel.com>
>
> A major point of the GPU scheduler is that it re-orders batch buffers after they
> have been submitted to the driver. Rather than attempting to re-assign seqno
> values, it is much simpler to have each batch buffer keep its initially assigned
> number and modify the rest of the driver to cope with seqnos being returned out
> of order. In practice, very little code actually needs updating to cope.
>
> One such place is the retire request handler. Rather than stopping as soon as an
> uncompleted seqno is found, it must now keep iterating through the requests in
> case later seqnos have completed. There is also a problem with doing the free of
> the request before the move to inactive. Thus the requests are now moved to a
> temporary list first, then the objects de-activated and finally the requests on
> the temporary list are freed.
> ---
> drivers/gpu/drm/i915/i915_gem.c | 60 +++++++++++++++++++++------------------
> 1 file changed, 32 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index b784eb2..7e53446 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2602,7 +2602,10 @@ void i915_gem_reset(struct drm_device *dev)
> void
> i915_gem_retire_requests_ring(struct intel_engine_cs *ring)
> {
> + struct drm_i915_gem_object *obj, *obj_next;
> + struct drm_i915_gem_request *req, *req_next;
> uint32_t seqno;
> + LIST_HEAD(deferred_request_free);
>
> if (list_empty(&ring->request_list))
> return;
> @@ -2611,43 +2614,35 @@ i915_gem_retire_requests_ring(struct intel_engine_cs *ring)
>
> seqno = ring->get_seqno(ring, true);
>
> - /* Move any buffers on the active list that are no longer referenced
> - * by the ringbuffer to the flushing/inactive lists as appropriate,
> - * before we free the context associated with the requests.
> + /* Note that seqno values might be out of order due to rescheduling and
> + * pre-emption. Thus both lists must be processed in their entirety
> + * rather than stopping at the first 'non-passed' entry.
> */
> - while (!list_empty(&ring->active_list)) {
> - struct drm_i915_gem_object *obj;
> -
> - obj = list_first_entry(&ring->active_list,
> - struct drm_i915_gem_object,
> - ring_list);
> -
> - if (!i915_seqno_passed(seqno, obj->last_read_seqno))
> - break;
>
> - i915_gem_object_move_to_inactive(obj);
> - }
> -
> -
> - while (!list_empty(&ring->request_list)) {
> - struct drm_i915_gem_request *request;
> -
> - request = list_first_entry(&ring->request_list,
> - struct drm_i915_gem_request,
> - list);
> -
> - if (!i915_seqno_passed(seqno, request->seqno))
> - break;
> + list_for_each_entry_safe(req, req_next, &ring->request_list, list) {
> + if (!i915_seqno_passed(seqno, req->seqno))
> + continue;
>
> - trace_i915_gem_request_retire(ring, request->seqno);
> + trace_i915_gem_request_retire(ring, req->seqno);
> /* We know the GPU must have read the request to have
> * sent us the seqno + interrupt, so use the position
> * of tail of the request to update the last known position
> * of the GPU head.
> */
> - ring->buffer->last_retired_head = request->tail;
> + ring->buffer->last_retired_head = req->tail;
>
> - i915_gem_free_request(request);
> + list_move_tail(&req->list, &deferred_request_free);
> + }
> +
> + /* Move any buffers on the active list that are no longer referenced
> + * by the ringbuffer to the flushing/inactive lists as appropriate,
> + * before we free the context associated with the requests.
> + */
> + list_for_each_entry_safe(obj, obj_next, &ring->active_list, ring_list) {
> + if (!i915_seqno_passed(seqno, obj->last_read_seqno))
> + continue;
> +
> + i915_gem_object_move_to_inactive(obj);
> }
>
> if (unlikely(ring->trace_irq_seqno &&
> @@ -2656,6 +2651,15 @@ i915_gem_retire_requests_ring(struct intel_engine_cs *ring)
> ring->trace_irq_seqno = 0;
> }
>
> + /* Finish processing active list before freeing request */
> + while (!list_empty(&deferred_request_free)) {
> + req = list_first_entry(&deferred_request_free,
> + struct drm_i915_gem_request,
> + list);
> +
> + i915_gem_free_request(req);
> + }
> +
> WARN_ON(i915_verify_lists(ring->dev));
> }
>
I think this looks ok, but I don't look at this code much... Seems
like it should be fine to go in as-is, though I do worry a little about
the additional time we'll spend walking the list if we have lots of
outstanding requests. But since this is just called in a work queue,
maybe that's fine.
Going forward, I guess we might want per-context seqno tracking
instead, with more limited preemption within a context (or maybe
none?), which might make things easier. But that would require a bit
more restructuring...
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
--
Jesse Barnes, Intel Open Source Technology Center
next prev parent reply other threads:[~2014-07-02 18:10 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-26 17:23 [RFC 00/44] GPU scheduler for i915 driver John.C.Harrison
2014-06-26 17:23 ` [RFC 01/44] drm/i915: Corrected 'file_priv' to 'file' in 'i915_driver_preclose()' John.C.Harrison
2014-06-30 21:03 ` Jesse Barnes
2014-07-07 18:02 ` Daniel Vetter
2014-06-26 17:23 ` [RFC 02/44] drm/i915: Added getparam for native sync John.C.Harrison
2014-07-07 18:52 ` Daniel Vetter
2014-06-26 17:23 ` [RFC 03/44] drm/i915: Add extra add_request calls John.C.Harrison
2014-06-30 21:10 ` Jesse Barnes
2014-07-07 18:41 ` Daniel Vetter
2014-07-08 7:44 ` Chris Wilson
2014-06-26 17:23 ` [RFC 04/44] drm/i915: Fix null pointer dereference in error capture John.C.Harrison
2014-06-30 21:40 ` Jesse Barnes
2014-07-01 7:12 ` Chris Wilson
2014-07-07 18:49 ` Daniel Vetter
2014-07-01 7:20 ` [PATCH] drm/i915: Remove num_pages parameter to i915_error_object_create() Chris Wilson
2014-06-26 17:23 ` [RFC 05/44] drm/i915: Updating assorted register and status page definitions John.C.Harrison
2014-07-02 17:49 ` Jesse Barnes
2014-06-26 17:23 ` [RFC 06/44] drm/i915: Fixes for FIFO space queries John.C.Harrison
2014-07-02 17:50 ` Jesse Barnes
2014-06-26 17:23 ` [RFC 07/44] drm/i915: Disable 'get seqno' workaround for VLV John.C.Harrison
2014-07-02 17:51 ` Jesse Barnes
2014-07-07 18:56 ` Daniel Vetter
2014-06-26 17:23 ` [RFC 08/44] drm/i915: Added GPU scheduler config option John.C.Harrison
2014-07-07 18:58 ` Daniel Vetter
2014-06-26 17:24 ` [RFC 09/44] drm/i915: Start of GPU scheduler John.C.Harrison
2014-07-02 17:55 ` Jesse Barnes
2014-07-07 19:02 ` Daniel Vetter
2014-06-26 17:24 ` [RFC 10/44] drm/i915: Prepare retire_requests to handle out-of-order seqnos John.C.Harrison
2014-07-02 18:11 ` Jesse Barnes [this message]
2014-07-07 19:05 ` Daniel Vetter
2014-07-09 14:08 ` Daniel Vetter
2014-06-26 17:24 ` [RFC 11/44] drm/i915: Added scheduler hook into i915_seqno_passed() John.C.Harrison
2014-07-02 18:14 ` Jesse Barnes
2014-06-26 17:24 ` [RFC 12/44] drm/i915: Disable hardware semaphores when GPU scheduler is enabled John.C.Harrison
2014-07-02 18:16 ` Jesse Barnes
2014-06-26 17:24 ` [RFC 13/44] drm/i915: Added scheduler hook when closing DRM file handles John.C.Harrison
2014-07-02 18:20 ` Jesse Barnes
2014-07-23 15:10 ` John Harrison
2014-07-23 15:39 ` Jesse Barnes
2014-06-26 17:24 ` [RFC 14/44] drm/i915: Added getparam for GPU scheduler John.C.Harrison
2014-07-02 18:21 ` Jesse Barnes
2014-07-07 19:11 ` Daniel Vetter
2014-06-26 17:24 ` [RFC 15/44] drm/i915: Added deferred work handler for scheduler John.C.Harrison
2014-07-07 19:14 ` Daniel Vetter
2014-07-23 15:37 ` John Harrison
2014-07-23 18:50 ` Daniel Vetter
2014-07-24 15:42 ` John Harrison
2014-07-25 7:18 ` Daniel Vetter
2014-06-26 17:24 ` [RFC 16/44] drm/i915: Alloc early seqno John.C.Harrison
2014-07-02 18:29 ` Jesse Barnes
2014-07-23 15:11 ` John Harrison
2014-06-26 17:24 ` [RFC 17/44] drm/i915: Prelude to splitting i915_gem_do_execbuffer in two John.C.Harrison
2014-07-02 18:34 ` Jesse Barnes
2014-07-07 19:21 ` Daniel Vetter
2014-07-23 16:33 ` John Harrison
2014-07-23 18:14 ` Daniel Vetter
2014-06-26 17:24 ` [RFC 18/44] drm/i915: Added scheduler debug macro John.C.Harrison
2014-07-02 18:37 ` Jesse Barnes
2014-07-07 19:23 ` Daniel Vetter
2014-06-26 17:24 ` [RFC 19/44] drm/i915: Split i915_dem_do_execbuffer() in half John.C.Harrison
2014-06-26 17:24 ` [RFC 20/44] drm/i915: Redirect execbuffer_final() via scheduler John.C.Harrison
2014-06-26 17:24 ` [RFC 21/44] drm/i915: Added tracking/locking of batch buffer objects John.C.Harrison
2014-06-26 17:24 ` [RFC 22/44] drm/i915: Ensure OLS & PLR are always in sync John.C.Harrison
2014-06-26 17:24 ` [RFC 23/44] drm/i915: Added manipulation of OLS/PLR John.C.Harrison
2014-06-26 17:24 ` [RFC 24/44] drm/i915: Added scheduler interrupt handler hook John.C.Harrison
2014-06-26 17:24 ` [RFC 25/44] drm/i915: Added hook to catch 'unexpected' ring submissions John.C.Harrison
2014-06-26 17:24 ` [RFC 26/44] drm/i915: Added scheduler support to __wait_seqno() calls John.C.Harrison
2014-06-26 17:24 ` [RFC 27/44] drm/i915: Added scheduler support to page fault handler John.C.Harrison
2014-06-26 17:24 ` [RFC 28/44] drm/i915: Added scheduler flush calls to ring throttle and idle functions John.C.Harrison
2014-06-26 17:24 ` [RFC 29/44] drm/i915: Hook scheduler into intel_ring_idle() John.C.Harrison
2014-06-26 17:24 ` [RFC 30/44] drm/i915: Added a module parameter for allowing scheduler overrides John.C.Harrison
2014-06-26 17:24 ` [RFC 31/44] drm/i915: Implemented the GPU scheduler John.C.Harrison
2014-06-26 17:24 ` [RFC 32/44] drm/i915: Added immediate submission override to scheduler John.C.Harrison
2014-06-26 17:24 ` [RFC 33/44] drm/i915: Added trace points " John.C.Harrison
2014-06-26 17:24 ` [RFC 34/44] drm/i915: Added scheduler queue throttling by DRM file handle John.C.Harrison
2014-06-26 17:24 ` [RFC 35/44] drm/i915: Added debugfs interface to scheduler tuning parameters John.C.Harrison
2014-06-26 17:24 ` [RFC 36/44] drm/i915: Added debug state dump facilities to scheduler John.C.Harrison
2014-06-26 17:24 ` [RFC 37/44] drm/i915: Added facility for cancelling an outstanding request John.C.Harrison
2014-06-26 17:24 ` [RFC 38/44] drm/i915: Add early exit to execbuff_final() if insufficient ring space John.C.Harrison
2014-06-26 17:24 ` [RFC 39/44] drm/i915: Added support for pre-emptive scheduling John.C.Harrison
2014-06-26 17:24 ` [RFC 40/44] drm/i915: REVERTME Hack to allow IGT to test pre-emption John.C.Harrison
2014-06-26 17:24 ` [RFC 41/44] drm/i915: Added validation callback to trace points John.C.Harrison
2014-06-26 17:24 ` [RFC 42/44] drm/i915: Added scheduler statistic reporting to debugfs John.C.Harrison
2014-06-26 17:24 ` [RFC 43/44] drm/i915: Added support for submitting out-of-batch ring commands John.C.Harrison
2014-06-26 17:24 ` [RFC 44/44] drm/i915: Fake batch support for page flips John.C.Harrison
2014-07-07 19:25 ` Daniel Vetter
2014-06-26 20:44 ` [RFC 00/44] GPU scheduler for i915 driver Dave Airlie
2014-07-07 15:57 ` Daniel Vetter
2014-10-10 10:35 ` Steven Newbury
2014-10-20 10:31 ` John Harrison
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=20140702111136.54065e21@jbarnes-desktop \
--to=jbarnes@virtuousgeek.org \
--cc=Intel-GFX@lists.freedesktop.org \
--cc=John.C.Harrison@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