1. 08 2月, 2017 1 次提交
    • C
      drm/i915: Restore context and pd for ringbuffer submission after reset · c0dcb203
      Chris Wilson 提交于
      Following a reset, the context and page directory registers are lost.
      However, the queue of requests that we resubmit after the reset may
      depend upon them - the registers are restored from a context image, but
      that restore may be inhibited and may simply be absent from the request
      if it was in the middle of a sequence using the same context. If we
      prime the CCID/PD registers with the first request in the queue (even
      for the hung request), we prevent invalid memory access for the
      following requests (and continually hung engines).
      
      v2: Magic BIT(8), reserved for future use but still appears unused.
      v3: Some commentary on handling innocent vs guilty requests
      v4: Add a wait for PD_BASE fetch. The reload appears to be instant on my
      Ivybridge, but this bit probably exists for a reason.
      
      Fixes: 821ed7df ("drm/i915: Update reset path to fix incomplete requests")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170207152437.4252-1-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
      c0dcb203
  2. 07 2月, 2017 1 次提交
  3. 06 2月, 2017 2 次提交
  4. 01 2月, 2017 2 次提交
  5. 30 1月, 2017 2 次提交
  6. 25 1月, 2017 2 次提交
  7. 24 1月, 2017 4 次提交
  8. 23 1月, 2017 6 次提交
  9. 19 1月, 2017 1 次提交
  10. 18 1月, 2017 1 次提交
    • F
      drm/i915: Remove WaDisableLSQCROPERFforOCL KBL workaround. · 4fc020d8
      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
      (cherry picked from commit 8726f2fa)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      4fc020d8
  11. 13 1月, 2017 1 次提交
  12. 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
  13. 11 1月, 2017 1 次提交
  14. 07 1月, 2017 1 次提交
  15. 05 1月, 2017 2 次提交
  16. 31 12月, 2016 1 次提交
  17. 24 12月, 2016 2 次提交
  18. 20 12月, 2016 1 次提交
  19. 19 12月, 2016 4 次提交
  20. 16 12月, 2016 1 次提交
  21. 06 12月, 2016 1 次提交
  22. 02 12月, 2016 1 次提交