All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: "O'Rourke, Tom" <Tom.O'Rourke@intel.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 0/9 v6] Batch submission via GuC
Date: Fri, 14 Aug 2015 11:09:20 +0200	[thread overview]
Message-ID: <20150814090920.GS17734@phenom.ffwll.local> (raw)
In-Reply-To: <20150813023510.GA150199@torourke-desk1>

On Wed, Aug 12, 2015 at 07:35:10PM -0700, O'Rourke, Tom wrote:
> On Wed, Aug 12, 2015 at 07:57:37AM -0700, Gordon, David S wrote:
> > On 12/08/15 15:43, Dave Gordon wrote:
> > > This patch series enables command submission via the GuC. In this mode,
> > > instead of the host CPU driving the execlist port directly, it hands
> > > over work items to the GuC, using a doorbell mechanism to tell the GuC
> > > that new items have been added to its work queue. The GuC then dispatches
> > > contexts to the various GPU engines, and manages the resulting context-
> > > switch interrupts. Completion of a batch is however still signalled to
> > > the CPU; the GuC is not involved in handling user interrupts.
> > >
> > > There are two subsequences within the patch series:
> > >
> > >    drm/i915: GuC-specific firmware loader
> > >    drm/i915: Debugfs interface to read GuC load status
> > >
> > > These two patches provide the GuC loader and a debugfs interface to
> > > verify the resulting state.  At this point in the sequence we can load
> > > and activate the GuC firmware, but not submit any batches through it.
> > > (This is nonetheless a potentially useful state, as the GuC could do
> > > other useful work even when not handling batch submissions).
> > >
> > >    drm/i915: Expose one LRC function for GuC submission mode
> > >    drm/i915: Prepare for GuC-based command submission
> > >    drm/i915: Enable GuC firmware log
> > >    drm/i915: Implementation of GuC submission client
> > >    drm/i915: Interrupt routing for GuC submission
> > >    drm/i915: Integrate GuC-based command submission
> > >    drm/i915: Debugfs interface for GuC submission statistics
> > >
> > > In this second section, we implement the GuC submission mechanism, and
> > > link it into the (execlist-based) submission path. At this stage, it is
> > > not yet enabled by default; it is activated only if the kernel command
> > > line explicitly switches it on.
> > >
> > > The GuC firmware itself is not included in this patchset; it is or will
> > > be available for download from https://01.org/linuxgraphics/downloads/
> > > This driver works with and requires GuC firmware revision 3.x. It will
> > > not work with any firmware version 1.x, as the GuC protocol in those
> > > revisions was incompatible and is no longer supported.
> > >
> > > On platforms where there is no GuC, or where GuC submission is not
> > > specifically enabled, batch submission will continue to use the execlist
> > > (or ringbuffer) mechanisms.  On the other hand, if GuC submission is
> > > requested but the GuC firmware cannot be found or is invalid, the GPU
> > > will be unusable.
> > >
> > > It is expected that a subsequent patch will enable GuC submission by
> > > default once the signed firmware is published on 01.org.
> > >
> > > Ben Widawsky (0):
> > > Vinit Azad (0):
> > > Michael H. Nguyen (0):
> > >    created the original versions on which some of these patches are based.
> > >
> > > Alex Dai (5):
> > >    drm/i915: GuC-specific firmware loader
> > >    drm/i915: Debugfs interface to read GuC load status
> > >    drm/i915: Prepare for GuC-based command submission
> > >    drm/i915: Enable GuC firmware log
> > >    drm/i915: Integrate GuC-based command submission
> > >
> > > Dave Gordon (4):
> > >    drm/i915: Expose one LRC function for GuC submission mode
> > >    drm/i915: Implementation of GuC submission client
> > >    drm/i915: Interrupt routing for GuC submission
> > >    drm/i915: Debugfs interface for GuC submission statistics
> > >
> > >   Documentation/DocBook/drm.tmpl             |  14 +
> > >   drivers/gpu/drm/i915/Makefile              |   4 +
> > >   drivers/gpu/drm/i915/i915_debugfs.c        | 146 ++++-
> > >   drivers/gpu/drm/i915/i915_dma.c            |   9 +
> > >   drivers/gpu/drm/i915/i915_drv.h            |  11 +
> > >   drivers/gpu/drm/i915/i915_gem.c            |  16 +
> > >   drivers/gpu/drm/i915/i915_gpu_error.c      |  14 +-
> > >   drivers/gpu/drm/i915/i915_guc_reg.h        |  17 +-
> > >   drivers/gpu/drm/i915/i915_guc_submission.c | 901 +++++++++++++++++++++++++++++
> > >   drivers/gpu/drm/i915/i915_reg.h            |  15 +-
> > >   drivers/gpu/drm/i915/intel_guc.h           | 122 ++++
> > >   drivers/gpu/drm/i915/intel_guc_fwif.h      |   9 +-
> > >   drivers/gpu/drm/i915/intel_guc_loader.c    | 611 +++++++++++++++++++
> > >   drivers/gpu/drm/i915/intel_lrc.c           |  65 ++-
> > >   drivers/gpu/drm/i915/intel_lrc.h           |   8 +
> > >   15 files changed, 1918 insertions(+), 44 deletions(-)
> > >   create mode 100644 drivers/gpu/drm/i915/i915_guc_submission.c
> > >   create mode 100644 drivers/gpu/drm/i915/intel_guc.h
> > >   create mode 100644 drivers/gpu/drm/i915/intel_guc_loader.c
> > 
> > Tom O'Rourke has already R-B'ed the previous [v5] versions of these, and 
> > there are no substantive changes to patches 2, 3, 4, 5, 7 and 8, so we 
> > can carry that over; also, the change in patch 1 is just an update to a 
> > comment noted in Tom's earlier reviews as being out-of-date.
> > 
> > I haven't included patch 10 (enable-by-default) as we've decided to wait 
> > until the signed firmware is publicly available on 01.org before
> > making it the default.
> > 
> > So, it's really just patches 6/9 and 9/9 that need a re-review from Tom.
> > 
> > Thanks,
> > .Dave.
> 
> [TOR:] These patches still look good.  Good catch in patch 6 with the offset.
> 
> For all 9 patches:
> Reviewed-by: Tom O'Rourke <Tom.O'Rourke@intel.com>

All merged to dinq, thanks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

      reply	other threads:[~2015-08-14  9:09 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-12 14:43 [PATCH 0/9 v6] Batch submission via GuC Dave Gordon
2015-08-12 14:43 ` [PATCH 1/9 v6] drm/i915: GuC-specific firmware loader Dave Gordon
2015-08-14  9:05   ` Daniel Vetter
2015-08-12 14:43 ` [PATCH 2/9 v6] drm/i915: Debugfs interface to read GuC load status Dave Gordon
2015-08-12 14:43 ` [PATCH 3/9 v6] drm/i915: Expose one LRC function for GuC submission mode Dave Gordon
2015-08-12 14:43 ` [PATCH 4/9 v6] drm/i915: Prepare for GuC-based command submission Dave Gordon
2015-08-12 14:43 ` [PATCH 5/9 v6] drm/i915: Enable GuC firmware log Dave Gordon
2015-08-12 14:43 ` [PATCH 6/9 v6] drm/i915: Implementation of GuC submission client Dave Gordon
2015-08-12 14:43 ` [PATCH 7/9 v6] drm/i915: Interrupt routing for GuC submission Dave Gordon
2015-08-12 14:43 ` [PATCH 8/9 v6] drm/i915: Integrate GuC-based command submission Dave Gordon
2015-08-12 14:43 ` [PATCH 9/9 v6] drm/i915: Debugfs interface for GuC submission statistics Dave Gordon
2015-08-12 14:57 ` [PATCH 0/9 v6] Batch submission via GuC Dave Gordon
2015-08-13  2:35   ` O'Rourke, Tom
2015-08-14  9:09     ` Daniel Vetter [this message]

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=20150814090920.GS17734@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=Tom.O'Rourke@intel.com \
    --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 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.