[Intel-gfx] [PATCH 00/15] Batch submission via GuC

[Chris Wilson]

On Thu, Jun 25, 2015 at 08:23:08AM +0100, Dave Gordon wrote:
> On 17/06/15 13:43, Daniel Vetter wrote:
> > On Mon, Jun 15, 2015 at 07:36:18PM +0100, 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 three subsequences within the patch series:
> >>
> >>   drm/i915: Add i915_gem_object_write() to i915_gem.c
> >>   drm/i915: Embedded microcontroller (uC) firmware loading support
> >>
> >> These first two patches provide a generic framework for fetching the
> >> firmware that may be required by any embedded microcontroller from a
> >> file, using an asynchronous thread so that driver initialisation can
> >> continue while the firmware is being fetched. It is hoped that this
> >> framework is sufficiently general that it can be used for all curent
> >> and future microcontrollers.
> >>
> >>   drm/i915: Add GuC-related module parameters
> >>   drm/i915: Add GuC-related header files
> >>   drm/i915: GuC-specific firmware loader
> >>   drm/i915: Debugfs interface to read GuC load status
> > 
> > Does that include all the nifty power management stuff GuC does?
> 
> No; the GuC f/w may be doing such things but I don't have any code to
> interrogate it about power management. None of that appears in the GuC
> submission HLD, so I'd guess we're not presenting that until it has a
> stable i/f.
> 
> >> These four patches complete the GuC loader. 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
> >> can do other useful work even when not handling batch submissions).
> >>
> >>   drm/i915: Defer default hardware context initialisation until first
> >>   drm/i915: Move execlists defines from .c to .h
> >>   drm/i915: GuC submission setup, phase 1
> >>   drm/i915: Enable GuC firmware log
> >>   drm/i915: Implementation of GuC client
> >>   drm/i915: Interrupt routing for GuC submission
> >>   drm/i915: Integrate GuC-based command submission
> >>   drm/i915: Debugfs interface for GuC submission statistics
> >>   Documentation/drm: kerneldoc for GuC
> >>   drm/i915: Enable GuC submission, where supported
> >>
> >> In the final section, we implement the GuC submission mechanism, link
> >> it into the (execlist-based) submission path, and finally enable it
> >> (on supported platforms). On platforms where there is no GuC, or if
> >> the GuC firmware cannot be found or is invalid, batch submission will
> >> revert to using the execlist mechanism directly.
> > 
> > I thought we had some perf data showing that GuC is now faster than
> > execbuf ... Where's that?
> 
> Alex has run some benchmarks, generally showing a small improvement, up
> to about 5% depending on workload. OTOH John H knows of one application
> that improved by more than 20% :)

Is this compared to execlists? Big deal, we now that ELSP is very slow
and need to tackle the regressions introduced by the switch to
execlists in current gen.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre