1. 09 11月, 2017 7 次提交
    • C
      drm/i915: Prune the reservation shared fence array · 398c13b9
      Chris Wilson 提交于
      The shared fence array is not autopruning and may continue to grow as an
      object is shared between new timelines. Take the opportunity when we
      think the object is idle (we have to confirm that any external fence is
      also signaled) to decouple all the fences.
      
      We apply a similar trick after waiting on an object, see commit
      e54ca977 ("drm/i915: Remove completed fences after a wait")
      
      v2: No longer need to handle the batch pool as a special case.
      v3: Need to trylock from within i915_vma_retire as this may be called
      form the shrinker - and we may later try to allocate underneath the
      reservation lock, so a deadlock is possible.
      
      References: https://bugs.freedesktop.org/show_bug.cgi?id=102936
      Fixes: d07f0e59 ("drm/i915: Move GEM activity tracking into a common struct reservation_object")
      Fixes: 80b204bc ("drm/i915: Enable multiple timelines")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171107220656.5020-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      (cherry picked from commit 1ab22356)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      398c13b9
    • C
      drm/i915: Idle the GPU before shinking everything · 0676e794
      Chris Wilson 提交于
      The handling of contexts are peculiar. Instead of tieing their vma to
      activity, we pin the context. This means that we cannot simply unbind
      the context object itself at will (which would normally cause us to wait
      for the vma to be idle), but must manually idle the GPU and retire
      requests first.
      
      A consequence of this peculiarity is when doing a last desperate attempt
      to recover memory. If the memory is tied up inside active context
      objects, we will fail to recover any memory simply by trying to unbind
      the objects without first doing a wait-for-idle.
      
      A side-effect of removing the call to shrinker_lock_uninterruptible()
      from i915_gem_shrinker_oom() was that we removed an unlocked
      wait-for-idle, and so lost the "natural" shrinkage of context objects.
      By replacing that with a locked wait from inside i915_gem_shrink(), we
      not only replace it with the ability to recover all context objects, but
      do so for all i915_gem_shrink_all() callers.
      
      v2: Switching requires request allocation, which is not permitted from
      inside the shrinker as it only uses ordinary allocations.
      
      References: https://bugs.freedesktop.org/show_bug.cgi?id=102936
      Fixes: f2123818 ("drm/i915: Move dev_priv->mm.[un]bound_list to its own lock")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171108094400.1386-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      (cherry picked from commit 2f6a3783)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      0676e794
    • C
      drm/i915: Lock llist_del_first() vs llist_del_all() · 0f763ff3
      Chris Wilson 提交于
      An oversight in commit 87701b4b ("drm/i915: Only free the oldest
      stale object before a fresh allocation") was that not only do we have to
      serialise concurrent users of llist_del_first(), but we also have to
      lock llist_del_first() vs llist_del_all().
      
      From llist.h,
      
       * This can be summarized as follows:
       *
       *           |   add    | del_first |  del_all
       * add       |    -     |     -     |     -
       * del_first |          |     L     |     L
       * del_all   |          |           |     -
       *
       * Where, a particular row's operation can happen concurrently with a column's
       * operation, with "-" being no lock needed, while "L" being lock is needed.
      
      This should hopefully explain:
      
      <4>[   89.287106] general protection fault: 0000 [#1] PREEMPT SMP
      <4>[   89.287126] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp coretemp i915 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core r8169 mii mei_me mei snd_pcm prime_numbers i2c_hid pinctrl_geminilake pinctrl_intel
      <4>[   89.287226] CPU: 2 PID: 23 Comm: ksoftirqd/2 Tainted: G     U          4.14.0-rc8-CI-CI_DRM_3315+ #1
      <4>[   89.287247] Hardware name: Intel Corp. Geminilake/GLK RVP2 LP4SD (07), BIOS GELKRVPA.X64.0062.B30.1708222146 08/22/2017
      <4>[   89.287270] task: ffff88017ab34ec0 task.stack: ffffc90000128000
      <4>[   89.287290] RIP: 0010:llist_add_batch+0x4/0x20
      <4>[   89.287301] RSP: 0018:ffffc9000012bdb8 EFLAGS: 00010296
      <4>[   89.287314] RAX: ffffffff811017ad RBX: 6e468801a1560000 RCX: ef3e53fceecdeb81
      <4>[   89.287330] RDX: 6e468801a1566130 RSI: ffff880103d73d98 RDI: ffff880103d73d98
      <4>[   89.287346] RBP: ffffc9000012bdb8 R08: ffff88017ab35780 R09: 0000000000000000
      <4>[   89.287361] R10: ffffc9000012bd68 R11: 00000000abb18c3d R12: ffffffffa01369e0
      <4>[   89.287377] R13: ffff88017fd1b8f8 R14: ffff88017ab34ec0 R15: 000000000000000a
      <4>[   89.287393] FS:  0000000000000000(0000) GS:ffff88017fd00000(0000) knlGS:0000000000000000
      <4>[   89.287411] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      <4>[   89.287424] CR2: 00007ff0c0755018 CR3: 000000016df9b000 CR4: 00000000003406e0
      <4>[   89.287440] Call Trace:
      <4>[   89.287511]  __i915_gem_free_object_rcu+0x20/0x40 [i915]
      <4>[   89.287527]  rcu_process_callbacks+0x27a/0x730
      <4>[   89.287544]  __do_softirq+0xc0/0x4ae
      <4>[   89.287559]  ? smpboot_thread_fn+0x2d/0x280
      <4>[   89.287571]  run_ksoftirqd+0x1f/0x70
      <4>[   89.287582]  smpboot_thread_fn+0x18a/0x280
      <4>[   89.287595]  kthread+0x114/0x150
      <4>[   89.287605]  ? sort_range+0x30/0x30
      <4>[   89.287615]  ? kthread_create_on_node+0x40/0x40
      <4>[   89.287628]  ret_from_fork+0x27/0x40
      <4>[   89.287641] Code: 0d 48 83 ea 01 4c 89 c1 48 83 fa ff 74 12 48 23 0c d7 74 ed 48 c1 e2 06 48 0f bd c9 48 8d 04 0a 5d c3 90 90 90 90 90 55 48 89 e5 <48> 8b 0a 48 89 0e 48 89 c8 f0 48 0f b1 3a 48 39 c1 75 ed 48 85
      <1>[   89.287774] RIP: llist_add_batch+0x4/0x20 RSP: ffffc9000012bdb8
      <4>[   89.287826] ---[ end trace e775d15174d8ae02 ]---
      
      (Lockless lists are only easy (and lockless) when only using
      llist_add/llist_del_all!)
      
      Fixes: 87701b4b ("drm/i915: Only free the oldest stale object before
      a fresh allocation")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171106111508.11941-1-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
      (cherry picked from commit f991c492)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      0f763ff3
    • M
      drm/i915: Calculate ironlake intermediate watermarks correctly, v2. · 90c702b8
      Maarten Lankhorst 提交于
      The watermarks it should calculate against are the old optimal watermarks.
      The currently active crtc watermarks are pure fiction, and are invalid in
      case of a nonblocking modeset, page flip enabling/disabling planes or any
      other reason.
      
      When the crtc is disabled or during a modeset the intermediate watermarks
      don't need to be programmed separately, and could be directly assigned
      to the optimal watermarks.
      
      Changes since v1:
      - Use intel_atomic_get_old_crtc_state. (ville)
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171019151341.4579-2-maarten.lankhorst@linux.intel.com
      [mlankhorst: Add cc stable and bugzilla link, since previous patch doesn't fix issue by itself]
      Cc: stable@vger.kernel.org #v4.8+
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102373
      (cherry picked from commit b6b178a7)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      90c702b8
    • J
      drm/i915: Disable lazy PPGTT page table optimization for vGPU · b58d4bef
      Joonas Lahtinen 提交于
      When running under virtualization (vGPU active), we must disable
      the lazy PPGTT page table initialization optimization introduced by
      commit 14826673 ("drm/i915: Only initialize partially filled
      pagetables").
      
      We must do this because GVT-g makes unduly assumptions about guest
      behaviour, which this optimization breaks. This results in following
      looking errors in the host:
      
      ERROR gvt: guest page write error -22, gfn 0x7ada8, pa 0x7ada89a8, var 0x6, len 1
      
      The real fix is to not to depend on i915 driver behaviour, but instead
      either rely on only the contracts that i915 has with the hardware, or
      add some paravirtualization. While the real fix is en route, it won't
      be finished in time for 4.15, so the best option is to disable the
      optimization for now when vGPU is active to avoid breaking 4.15 guests
      in existing VM environments.
      
      Fixes: 14826673 ("drm/i915: Only initialize partially filled pagetables")
      Suggested-by: NXiaolin Zhang <xiaolin.zhang@intel.com>
      Signed-off-by: NXiaolin Zhang <xiaolin.zhang@intel.com>
      [Joonas: Rewrote the commit message and added tags.]
      Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
      Cc: Zhi Wang <zhi.a.wang@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Matthew Auld <matthew.auld@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
      Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171023153209.10527-1-joonas.lahtinen@linux.intel.com
      (cherry picked from commit 22a8a4fc)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      b58d4bef
    • C
      drm/i915/execlists: Remove the priority "optimisation" · a2487174
      Chris Wilson 提交于
      Originally we set the priority to max upon inserting the request into
      the execlists queue (and removing it from the scheduler lists). We could
      then use the prio==INT_MAX as a shortcut within execlists_schedule() to
      detect the end of the dependency chain. Since commit 1f181225
      ("drm/i915/execlists: Keep request->priority for its lifetime") this is
      no longer true as we use the request completion as an indicator the
      schedule dependency chain is complete instead. (This allows us to then
      reschedule requests even when its context is in flight.) However, this
      makes the GEM_BUG_ON() inside execlists_schedule() racy as we may change
      the rq->prio at the same time. As the assertion is useful, let's keep
      the assertion and remove the micro-optimisation.
      
      Fixes: 1f181225 ("drm/i915/execlists: Keep request->priority for its lifetime")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Michał Winiarski <michal.winiarski@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171024115501.21033-1-chris@chris-wilson.co.ukReviewed-by: NMichał Winiarski <michal.winiarski@intel.com>
      (cherry picked from commit 64b80085)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      a2487174
    • C
      drm/i915: Filter out spurious execlists context-switch interrupts · 5d266692
      Chris Wilson 提交于
      Back in commit a4b2b015 ("drm/i915: Don't mark an execlists
      context-switch when idle") we noticed the presence of late
      context-switch interrupts. We were able to filter those out by looking
      at whether the ELSP remained active, but in commit beecec90
      ("drm/i915/execlists: Preemption!") that became problematic as we now
      anticipate receiving a context-switch event for preemption while ELSP
      may be empty. To restore the spurious interrupt suppression, add a
      counter for the expected number of pending context-switches and skip if
      we do not need to handle this interrupt to make forward progress.
      
      v2: Don't forget to switch on for preempt.
      v3: Reduce the counter to a on/off boolean tracker. Declare the HW as
      active when we first submit, and idle after the final completion event
      (with which we confirm the HW says it is idle), and track each source
      of activity separately. With a finite number of sources, it should aide
      us in debugging which gets stuck.
      
      Fixes: beecec90 ("drm/i915/execlists: Preemption!")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Michal Winiarski <michal.winiarski@intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171023213237.26536-3-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
      (cherry picked from commit 4a118ecb)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      5d266692
  2. 27 10月, 2017 4 次提交
  3. 25 10月, 2017 1 次提交
  4. 23 10月, 2017 1 次提交
  5. 21 10月, 2017 2 次提交
  6. 20 10月, 2017 2 次提交
  7. 19 10月, 2017 13 次提交
  8. 18 10月, 2017 10 次提交