Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 07 9月, 2020 5 次提交
  3. 01 5月, 2020 1 次提交
  5. 04 3月, 2020 1 次提交
  7. 18 2月, 2020 1 次提交
  9. 10 2月, 2020 1 次提交
  11. 15 1月, 2020 1 次提交
  13. 09 1月, 2020 1 次提交
  15. 03 1月, 2020 1 次提交
  17. 22 12月, 2019 1 次提交
  19. 21 12月, 2019 1 次提交
  21. 19 12月, 2019 1 次提交
  23. 24 10月, 2019 1 次提交
  25. 18 10月, 2019 1 次提交
  27. 08 10月, 2019 2 次提交
  29. 16 8月, 2019 2 次提交
  31. 10 8月, 2019 3 次提交
  33. 09 8月, 2019 1 次提交
  35. 08 8月, 2019 1 次提交
  37. 04 8月, 2019 1 次提交
  39. 29 7月, 2019 1 次提交
  41. 23 7月, 2019 1 次提交
  43. 22 6月, 2019 1 次提交
  45. 21 6月, 2019 3 次提交
  47. 20 6月, 2019 1 次提交
  49. 15 6月, 2019 2 次提交
    • C
      drm/i915: Replace engine->timeline with a plain list · 422d7df4
      由 Chris Wilson 提交于 
      To continue the onslaught of removing the assumption of a global
execution ordering, another casualty is the engine->timeline. Without an
actual timeline to track, it is overkill and we can replace it with a
much less grand plain list. We still need a list of requests inflight,
for the simple purpose of finding inflight requests (for retiring,
resetting, preemption etc).
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190614164606.15633-3-chris@chris-wilson.co.uk
      422d7df4
    • C
      drm/i915: Keep contexts pinned until after the next kernel context switch · ce476c80
      由 Chris Wilson 提交于 
      We need to keep the context image pinned in memory until after the GPU
has finished writing into it. Since it continues to write as we signal
the final breadcrumb, we need to keep it pinned until the request after
it is complete. Currently we know the order in which requests execute on
each engine, and so to remove that presumption we need to identify a
request/context-switch we know must occur after our completion. Any
request queued after the signal must imply a context switch, for
simplicity we use a fresh request from the kernel context.

The sequence of operations for keeping the context pinned until saved is:

 - On context activation, we preallocate a node for each physical engine
   the context may operate on. This is to avoid allocations during
   unpinning, which may be from inside FS_RECLAIM context (aka the
   shrinker)

 - On context deactivation on retirement of the last active request (which
   is before we know the context has been saved), we add the
   preallocated node onto a barrier list on each engine

 - On engine idling, we emit a switch to kernel context. When this
   switch completes, we know that all previous contexts must have been
   saved, and so on retiring this request we can finally unpin all the
   contexts that were marked as deactivated prior to the switch.

We can enhance this in future by flushing all the idle contexts on a
regular heartbeat pulse of a switch to kernel context, which will also
be used to check for hung engines.

v2: intel_context_active_acquire/_release
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190614164606.15633-1-chris@chris-wilson.co.uk
      ce476c80
  51. 28 5月, 2019 1 次提交
  53. 27 4月, 2019 3 次提交