1. 19 1月, 2017 1 次提交
  2. 13 1月, 2017 1 次提交
  3. 12 1月, 2017 2 次提交
    • F
      drm/i915: Remove WaDisableLSQCROPERFforOCL KBL workaround. · 8726f2fa
      Francisco Jerez 提交于
      The WaDisableLSQCROPERFforOCL workaround has the side effect of
      disabling an L3SQ optimization that has huge performance implications
      and is unlikely to be necessary for the correct functioning of usual
      graphic workloads.  Userspace is free to re-enable the workaround on
      demand, and is generally in a better position to determine whether the
      workaround is necessary than the DRM is (e.g. only during the
      execution of compute kernels that rely on both L3 fences and HDC R/W
      requests).
      
      The same workaround seems to apply to BDW (at least to production
      stepping G1) and SKL as well (the internal workaround database claims
      that it does for all steppings, while the BSpec workaround table only
      mentions pre-production steppings), but the DRM doesn't do anything
      beyond whitelisting the L3SQCREG4 register so userspace can enable it
      when it sees fit.  Do the same on KBL platforms.
      
      Improves performance of the GFXBench4 gl_manhattan31 benchmark by 60%,
      and gl_4 (AKA car chase) by 14% on a KBL GT2 running Mesa master --
      This is followed by a regression of 35% and 10% respectively for the
      same benchmarks and platform caused by my recent patch series
      switching userspace to use the dataport constant cache instead of the
      sampler to implement uniform pull constant loads, which caused us to
      hit more heavily the L3 cache (and on platforms other than KBL had the
      opposite effect of improving performance of the same two benchmarks).
      The overall effect on KBL of this change combined with the recent
      userspace change is respectively 4.6% and 2.6%.  SynMark2 OglShMapPcf
      was affected by the constant cache changes (though it improved as it
      did on other platforms rather than regressing), but is not
      significantly affected by this patch (with statistical significance of
      5% and sample size 20).
      
      v2: Drop some more code to avoid unused variable warning.
      
      Fixes: 738fa1b3 ("drm/i915/kbl: Add WaDisableLSQCROPERFforOCL")
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99256Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
      Cc: Matthew Auld <matthew.william.auld@gmail.com>
      Cc: Eero Tamminen <eero.t.tamminen@intel.com>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: beignet@lists.freedesktop.org
      Cc: <stable@vger.kernel.org> # v4.7+
      Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
      [Removed double Fixes tag]
      Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1484217894-20505-1-git-send-email-mika.kuoppala@intel.com
      8726f2fa
    • Z
      drm/i915: check ppgtt validity when init reg state · 34869776
      Zhenyu Wang 提交于
      Check if ppgtt is valid for context when init reg state. For gvt
      context which has no i915 allocated ppgtt, failed to check that
      would cause kernel null ptr reference error.
      
      v2: remove !48bit ppgtt case as we'll always update before submit (Chris)
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170109131453.3943-1-zhenyuw@linux.intel.com
      34869776
  4. 11 1月, 2017 1 次提交
  5. 07 1月, 2017 1 次提交
  6. 05 1月, 2017 2 次提交
  7. 31 12月, 2016 1 次提交
  8. 24 12月, 2016 2 次提交
  9. 20 12月, 2016 1 次提交
  10. 19 12月, 2016 4 次提交
  11. 16 12月, 2016 1 次提交
  12. 06 12月, 2016 1 次提交
  13. 02 12月, 2016 1 次提交
  14. 29 11月, 2016 1 次提交
  15. 17 11月, 2016 2 次提交
  16. 15 11月, 2016 3 次提交
  17. 07 11月, 2016 1 次提交
    • I
      drm/i915: Make sure engines are idle during GPU idling in LR mode · 0cb5670b
      Imre Deak 提交于
      We assume that the GPU is idle once receiving the seqno via the last
      request's user interrupt. In execlist mode the corresponding context
      completed interrupt can be delayed though and until this latter
      interrupt arrives we consider the request to be pending on the ELSP
      submit port. This can cause a problem during system suspend where this
      last request will be seen by the resume code as still pending. Such
      pending requests are normally replayed after a GPU reset, but during
      resume we reset both SW and HW tracking of the ring head/tail pointers,
      so replaying the pending request with its stale tail pointer will leave
      the ring in an inconsistent state. A subsequent request submission can
      lead then to the GPU executing from uninitialized area in the ring
      behind the above stale tail pointer.
      
      Fix this by making sure any pending request on the ELSP port is
      completed before suspending. I used a polling wait since the completion
      time I measured was <1ms and since normally we only need to wait during
      system suspend. GPU idling during runtime suspend is scheduled with a
      delay (currently 50-100ms) after the retirement of the last request at
      which point the context completed interrupt must have arrived already.
      
      The chance of this bug was increased by
      
      commit 1c777c5d
      Author: Imre Deak <imre.deak@intel.com>
      Date:   Wed Oct 12 17:46:37 2016 +0300
      
          drm/i915/hsw: Fix GPU hang during resume from S3-devices state
      
      but it could happen even without the explicit GPU reset, since we
      disable interrupts afterwards during the suspend sequence.
      
      v2:
      - Do an unlocked poll-wait first. (Chris)
      v3-4:
      - s/intel_lr_engines_idle/intel_execlists_idle/ and move
        i915.enable_execlists check to the new helper. (Chris)
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98470Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/1478510405-11799-3-git-send-email-imre.deak@intel.com
      0cb5670b
  18. 29 10月, 2016 6 次提交
  19. 14 10月, 2016 1 次提交
    • A
      drm/i915: Allocate intel_engine_cs structure only for the enabled engines · 3b3f1650
      Akash Goel 提交于
      With the possibility of addition of many more number of rings in future,
      the drm_i915_private structure could bloat as an array, of type
      intel_engine_cs, is embedded inside it.
      	struct intel_engine_cs engine[I915_NUM_ENGINES];
      Though this is still fine as generally there is only a single instance of
      drm_i915_private structure used, but not all of the possible rings would be
      enabled or active on most of the platforms. Some memory can be saved by
      allocating intel_engine_cs structure only for the enabled/active engines.
      Currently the engine/ring ID is kept static and dev_priv->engine[] is simply
      indexed using the enums defined in intel_engine_id.
      To save memory and continue using the static engine/ring IDs, 'engine' is
      defined as an array of pointers.
      	struct intel_engine_cs *engine[I915_NUM_ENGINES];
      dev_priv->engine[engine_ID] will be NULL for disabled engine instances.
      
      There is a text size reduction of 928 bytes, from 1028200 to 1027272, for
      i915.o file (but for i915.ko file text size remain same as 1193131 bytes).
      
      v2:
      - Remove the engine iterator field added in drm_i915_private structure,
        instead pass a local iterator variable to the for_each_engine**
        macros. (Chris)
      - Do away with intel_engine_initialized() and instead directly use the
        NULL pointer check on engine pointer. (Chris)
      
      v3:
      - Remove for_each_engine_id() macro, as the updated macro for_each_engine()
        can be used in place of it. (Chris)
      - Protect the access to Render engine Fault register with a NULL check, as
        engine specific init is done later in Driver load sequence.
      
      v4:
      - Use !!dev_priv->engine[VCS] style for the engine check in getparam. (Chris)
      - Kill the superfluous init_engine_lists().
      
      v5:
      - Cleanup the intel_engines_init() & intel_engines_setup(), with respect to
        allocation of intel_engine_cs structure. (Chris)
      
      v6:
      - Rebase.
      
      v7:
      - Optimize the for_each_engine_masked() macro. (Chris)
      - Change the type of 'iter' local variable to enum intel_engine_id. (Chris)
      - Rebase.
      
      v8: Rebase.
      
      v9: Rebase.
      
      v10:
      - For index calculation use engine ID instead of pointer based arithmetic in
        intel_engine_sync_index() as engine pointers are not contiguous now (Chris)
      - For appropriateness, rename local enum variable 'iter' to 'id'. (Joonas)
      - Use for_each_engine macro for cleanup in intel_engines_init() and remove
        check for NULL engine pointer in cleanup() routines. (Joonas)
      
      v11: Rebase.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NAkash Goel <akash.goel@intel.com>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1476378888-7372-1-git-send-email-akash.goel@intel.com
      3b3f1650
  20. 10 10月, 2016 3 次提交
  21. 07 10月, 2016 2 次提交
  22. 05 10月, 2016 2 次提交