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% :) >> 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. >> >> Prerequisites: GuC submission will expose existing inadequacies in >> some of the existing codepaths unless certain other patches are applied. >> In particular we will require some version of Michel Thierry's patch >> drm/i915/lrc: Update PDPx registers with lri commands >> (because the GuC support light-restore, which execlist mode doesn't), >> and my own >> drm/i915: Allocate OLR more safely (workaround until OLR goes away) >> because otherwise the changed timing means that there is an increased > > s/timing/much reduced ring space I presume? I think it's more likely timing, but of course it depends on total system activity as to what happens to be pinned (and therefore kmapped) at any particular instant. >> risk of writing to a ringbuffer that is not currently pinned & mapped, >> causing a kernel OOPS. > > Cheers, Daniel New version incorporating all feedback should appear later today. It would probably have been yesterday were there not conflicts between "drm/i915: Defer default hardware context initialisation until first open" and one of the AntiOLR patches which also splits init_hw() :( .Dave. _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
