1. 05 10月, 2021 4 次提交
  2. 24 9月, 2021 1 次提交
    • T
      drm/i915 Implement LMEM backup and restore for suspend / resume · c56ce956
      Thomas Hellström 提交于
      Just evict unpinned objects to system. For pinned LMEM objects,
      make a backup system object and blit the contents to that.
      
      Backup is performed in three steps,
      1: Opportunistically evict evictable objects using the gpu blitter.
      2: After gt idle, evict evictable objects using the gpu blitter. This will
      be modified in an upcoming patch to backup pinned objects that are not used
      by the blitter itself.
      3: Backup remaining pinned objects using memcpy.
      
      Also move uC suspend to after 2) to make sure we have a functional GuC
      during 2) if using GuC submission.
      
      v2:
      - Major refactor to make sure gem_exec_suspend@hang-SX subtests work, and
        suspend / resume works with a slightly modified GuC submission enabling
        patch series.
      
      v3:
      - Fix a potential use-after-free (Matthew Auld)
      - Use i915_gem_object_create_shmem() instead of
        i915_gem_object_create_region (Matthew Auld)
      - Minor simplifications (Matthew Auld)
      - Fix up kerneldoc for i195_ttm_restore_region().
      - Final lmem_suspend() call moved to i915_gem_backup_suspend from
        i915_gem_suspend_late, since the latter gets called at driver unload
        and we don't unnecessarily want to run it at that time.
      
      v4:
      - Interface change of ttm- & lmem suspend / resume functions to use
        flags rather than bools. (Matthew Auld)
      - Completely drop the i915_gem_backup_suspend change (Matthew Auld)
      Signed-off-by: NThomas Hellström <thomas.hellstrom@linux.intel.com>
      Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210922062527.865433-5-thomas.hellstrom@linux.intel.com
      c56ce956
  3. 19 9月, 2021 3 次提交
  4. 15 9月, 2021 1 次提交
  5. 04 8月, 2021 2 次提交
  6. 30 7月, 2021 1 次提交
  7. 28 7月, 2021 3 次提交
  8. 09 7月, 2021 1 次提交
    • J
      drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE · fe4751c3
      Jason Ekstrand 提交于
      This reverts commit 88be76cd ("drm/i915: Allow userspace to specify
      ringsize on construction").  This API was originally added for OpenCL
      but the compute-runtime PR has sat open for a year without action so we
      can still pull it out if we want.  I argue we should drop it for three
      reasons:
      
       1. If the compute-runtime PR has sat open for a year, this clearly
          isn't that important.
      
       2. It's a very leaky API.  Ring size is an implementation detail of the
          current execlist scheduler and really only makes sense there.  It
          can't apply to the older ring-buffer scheduler on pre-execlist
          hardware because that's shared across all contexts and it won't
          apply to the GuC scheduler that's in the pipeline.
      
       3. Having userspace set a ring size in bytes is a bad solution to the
          problem of having too small a ring.  There is no way that userspace
          has the information to know how to properly set the ring size so
          it's just going to detect the feature and always set it to the
          maximum of 512K.  This is what the compute-runtime PR does.  The
          scheduler in i915, on the other hand, does have the information to
          make an informed choice.  It could detect if the ring size is a
          problem and grow it itself.  Or, if that's too hard, we could just
          increase the default size from 16K to 32K or even 64K instead of
          relying on userspace to do it.
      
      Let's drop this API for now and, if someone decides they really care
      about solving this problem, they can do it properly.
      Signed-off-by: NJason Ekstrand <jason@jlekstrand.net>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210708154835.528166-2-jason@jlekstrand.net
      fe4751c3
  9. 17 6月, 2021 4 次提交
  10. 16 6月, 2021 1 次提交
  11. 11 6月, 2021 1 次提交
  12. 02 6月, 2021 1 次提交
  13. 20 5月, 2021 2 次提交
  14. 30 3月, 2021 1 次提交
  15. 29 3月, 2021 1 次提交
  16. 25 3月, 2021 1 次提交
  17. 20 3月, 2021 2 次提交
  18. 23 2月, 2021 1 次提交
  19. 17 2月, 2021 1 次提交
  20. 16 2月, 2021 1 次提交
  21. 08 2月, 2021 2 次提交
  22. 05 2月, 2021 1 次提交
  23. 26 1月, 2021 1 次提交
  24. 21 1月, 2021 1 次提交
  25. 16 1月, 2021 2 次提交