public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox