From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: John.C.Harrison@Intel.com, Intel-GFX@Lists.FreeDesktop.Org
Subject: Re: [RFC, 1/4] drm/i915: Convert requests to use struct fence
Date: Tue, 07 Apr 2015 11:18:54 +0200 [thread overview]
Message-ID: <5523A0FE.3000707@linux.intel.com> (raw)
In-Reply-To: <1426873717-10176-2-git-send-email-John.C.Harrison@Intel.com>
Hey,
Op 20-03-15 om 18:48 schreef John.C.Harrison@Intel.com:
> From: John Harrison <John.C.Harrison@Intel.com>
>
> There is a construct in the linux kernel called 'struct fence' that is intended
> to keep track of work that is executed on hardware. I.e. it solves the basic
> problem that the drivers 'struct drm_i915_gem_request' is trying to address. The
> request structure does quite a lot more than simply track the execution progress
> so is very definitely still required. However, the basic completion status side
> could be updated to use the ready made fence implementation and gain all the
> advantages that provides.
>
> This patch makes the first step of integrating a struct fence into the request.
> It replaces the explicit reference count with that of the fence. It also
> replaces the 'is completed' test with the fence's equivalent. Currently, that
> simply chains on to the original request implementation. A future patch will
> improve this.
>
> For: VIZ-5190
> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>
> ---
> drivers/gpu/drm/i915/i915_drv.h | 37 +++++++++------------
> drivers/gpu/drm/i915/i915_gem.c | 55 ++++++++++++++++++++++++++++---
> drivers/gpu/drm/i915/intel_lrc.c | 1 +
> drivers/gpu/drm/i915/intel_ringbuffer.c | 1 +
> drivers/gpu/drm/i915/intel_ringbuffer.h | 3 ++
> 5 files changed, 70 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index ce3a536..7dcaf8c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -50,6 +50,7 @@
> #include <linux/intel-iommu.h>
> #include <linux/kref.h>
> #include <linux/pm_qos.h>
> +#include <linux/fence.h>
>
> /* General customization:
> */
> @@ -2048,7 +2049,11 @@ void i915_gem_track_fb(struct drm_i915_gem_object *old,
> * initial reference taken using kref_init
> */
> struct drm_i915_gem_request {
> - struct kref ref;
> + /** Underlying object for implementing the signal/wait stuff.
> + * NB: Never call fence_later()! Due to lazy allocation, scheduler
> + * re-ordering, pre-emption, etc., there is no guarantee at all
> + * about the validity or sequentialiaty of the fence's seqno! */
> + struct fence fence;
Set fence.context differently for each per context timeline. :-)
>+static bool i915_gem_request_enable_signaling(struct fence *req_fence)
>+{
>+ WARN(true, "Is this required?");
>+ return true;
>+}
Yes, try calling fence_wait() on the fence. :-) This function should call irq_get and add itself to ring->irq_queue.
See for an example radeon_fence_enable_signaling.
>@@ -2557,6 +2596,8 @@ int i915_gem_request_alloc(struct intel_engine_cs *ring,
> return ret;
> }
>
>+ fence_init(&request->fence, &i915_gem_request_fops, &ring->fence_lock, ring->fence_context, request->seqno);
>+
> /*
> * Reserve space in the ring buffer for all the commands required to
> * eventually emit this request. This is to guarantee that the
Use ring->irq_queue.lock instead of making a new lock? This will make implementing enable_signaling easier too.
~Maarten
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-04-07 9:18 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-20 17:48 [RFC 0/4] Convert requests to use struct fence John.C.Harrison
2015-03-20 17:48 ` [RFC 1/4] drm/i915: " John.C.Harrison
2015-04-07 9:18 ` Maarten Lankhorst [this message]
2015-04-07 10:59 ` [RFC, " John Harrison
2015-04-07 11:18 ` Maarten Lankhorst
2015-04-17 19:22 ` Dave Gordon
2015-04-20 5:13 ` Maarten Lankhorst
2015-03-20 17:48 ` [RFC 2/4] drm/i915: Removed now redudant parameter to i915_gem_request_completed() John.C.Harrison
2015-04-17 18:57 ` Dave Gordon
2015-03-20 17:48 ` [RFC 3/4] drm/i915: Interrupt driven fences John.C.Harrison
2015-03-20 21:11 ` Chris Wilson
2015-03-23 9:22 ` Daniel Vetter
2015-03-23 12:13 ` John Harrison
2015-03-26 13:22 ` Daniel Vetter
2015-03-26 17:27 ` Jesse Barnes
2015-03-27 8:24 ` Daniel Vetter
2015-03-20 17:48 ` [RFC 4/4] drm/i915: Updated request structure tracing John.C.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=5523A0FE.3000707@linux.intel.com \
--to=maarten.lankhorst@linux.intel.com \
--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 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.