1. 01 Mar, 2016 2 commits
    • Tvrtko Ursulin's avatar
      drm/i915: Execlists small cleanups and micro-optimisations · c6a2ac71
      Tvrtko Ursulin authored
      Assorted changes in the areas of code cleanup, reduction of
      invariant conditional in the interrupt handler and lock
      contention and MMIO access optimisation.
      
       * Remove needless initialization.
       * Improve cache locality by reorganizing code and/or using
         branch hints to keep unexpected or error conditions out
         of line.
       * Favor busy submit path vs. empty queue.
       * Less branching in hot-paths.
      
      v2:
      
       * Avoid mmio reads when possible. (Chris Wilson)
       * Use natural integer size for csb indices.
       * Remove useless return value from execlists_update_context.
       * Extract 32-bit ppgtt PDPs update so it is out of line and
         shared with two callers.
       * Grab forcewake across all mmio operations to ease the
         load on uncore lock and use chepear mmio ops.
      
      v3:
      
       * Removed some more pointless u8 data types.
       * Removed unused return from execlists_context_queue.
       * Commit message updates.
      
      v4:
       * Unclumsify the unqueue if statement. (Chris Wilson)
       * Hide forcewake from the queuing function. (Chris Wilson)
      
      Version 3 now makes the irq handling code path ~20% smaller on
      48-bit PPGTT hardware, and a little bit less elsewhere. Hot
      paths are mostly in-line now and hammering on the uncore
      spinlock is greatly reduced together with mmio traffic to an
      extent.
      
      Benchmarking with "gem_latency -n 100" (keep submitting
      batches with 100 nop instruction) shows approximately 4% higher
      throughput, 2% less CPU time and 22% smaller latencies. This was
      on a big-core while small-cores could benefit even more.
      
      Most likely reason for the improvements are the MMIO
      optimization and uncore lock traffic reduction.
      
      One odd result is with "gem_latency -n 0" (dispatching empty
      batches) which shows 5% more throughput, 8% less CPU time,
      25% better producer and consumer latencies, but 15% higher
      dispatch latency which is yet unexplained.
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/1456505912-22286-1-git-send-email-tvrtko.ursulin@linux.intel.com
      c6a2ac71
    • Maarten Lankhorst's avatar
      drm/i915: Handle -EDEADLK in drm_atomic_commit from load-detect. · 3ba86073
      Maarten Lankhorst authored
      CI runs with DEBUG_WW_MUTEX_SLOWPATH, so -EDEADLK occurs a lot more.
      Handle the case where drm_atomic_commit fails with -EDEADLK correctly.
      Signed-off-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/56D3FEF1.6070306@linux.intel.comReviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      3ba86073
  2. 29 Feb, 2016 4 commits
    • Eric Engestrom's avatar
      drm/i915: remove dead code · d9f8e52b
      Eric Engestrom authored
      79e53945 ("DRM: i915: add mode setting
      support") added those variables but never used them.
      Signed-off-by: default avatarEric Engestrom <eric.engestrom@imgtec.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1456763047-28828-2-git-send-email-eric.engestrom@imgtec.com
      d9f8e52b
    • Eric Engestrom's avatar
      drm/i915: remove left over dead code · c3454d57
      Eric Engestrom authored
      ae80152d ("drm/i915: Rewrite VLV/CHV
      watermark code") removed everything that would have used those vars.
      Signed-off-by: default avatarEric Engestrom <eric.engestrom@imgtec.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1456763047-28828-1-git-send-email-eric.engestrom@imgtec.com
      c3454d57
    • Matt Roper's avatar
      drm/i915: Add two-stage ILK-style watermark programming (v11) · ed4a6a7c
      Matt Roper authored
      In addition to calculating final watermarks, let's also pre-calculate a
      set of intermediate watermark values at atomic check time.  These
      intermediate watermarks are a combination of the watermarks for the old
      state and the new state; they should satisfy the requirements of both
      states which means they can be programmed immediately when we commit the
      atomic state (without waiting for a vblank).  Once the vblank does
      happen, we can then re-program watermarks to the more optimal final
      value.
      
      v2: Significant rebasing/rewriting.
      
      v3:
       - Move 'need_postvbl_update' flag to CRTC state (Daniel)
       - Don't forget to check intermediate watermark values for validity
         (Maarten)
       - Don't due async watermark optimization; just do it at the end of the
         atomic transaction, after waiting for vblanks.  We do want it to be
         async eventually, but adding that now will cause more trouble for
         Maarten's in-progress work.  (Maarten)
       - Don't allocate space in crtc_state for intermediate watermarks on
         platforms that don't need it (gen9+).
       - Move WaCxSRDisabledForSpriteScaling:ivb into intel_begin_crtc_commit
         now that ilk_update_wm is gone.
      
      v4:
       - Add a wm_mutex to cover updates to intel_crtc->active and the
         need_postvbl_update flag.  Since we don't have async yet it isn't
         terribly important yet, but might as well add it now.
       - Change interface to program watermarks.  Platforms will now expose
         .initial_watermarks() and .optimize_watermarks() functions to do
         watermark programming.  These should lock wm_mutex, copy the
         appropriate state values into intel_crtc->active, and then call
         the internal program watermarks function.
      
      v5:
       - Skip intermediate watermark calculation/check during initial hardware
         readout since we don't trust the existing HW values (and don't have
         valid values of our own yet).
       - Don't try to call .optimize_watermarks() on platforms that don't have
         atomic watermarks yet.  (Maarten)
      
      v6:
       - Rebase
      
      v7:
       - Further rebase
      
      v8:
       - A few minor indentation and line length fixes
      
      v9:
       - Yet another rebase since Maarten's patches reworked a bunch of the
         code (wm_pre, wm_post, etc.) that this was previously based on.
      
      v10:
       - Move wm_mutex to dev_priv to protect against racing commits against
         disjoint CRTC sets. (Maarten)
       - Drop unnecessary clearing of cstate->wm.need_postvbl_update (Maarten)
      
      v11:
       - Now that we've moved to atomic watermark updates, make sure we call
         the proper function to program watermarks in
         {ironlake,haswell}_crtc_enable(); the failure to do so on the
         previous patch iteration led to us not actually programming the
         watermarks before turning on the CRTC, which was the cause of the
         underruns that the CI system was seeing.
       - Fix inverted logic for determining when to optimize watermarks.  We
         were needlessly optimizing when the intermediate/optimal values were
         the same (harmless), but not actually optimizing when they differed
         (also harmless, but wasteful from a power/bandwidth perspective).
      
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1456276813-5689-1-git-send-email-matthew.d.roper@intel.com
      ed4a6a7c
    • Daniel Vetter's avatar
      5790ff74
  3. 26 Feb, 2016 6 commits
  4. 25 Feb, 2016 4 commits
  5. 22 Feb, 2016 8 commits
  6. 19 Feb, 2016 4 commits
  7. 18 Feb, 2016 8 commits
  8. 17 Feb, 2016 4 commits