1. 21 3月, 2019 3 次提交
  2. 18 3月, 2019 1 次提交
  3. 08 3月, 2019 1 次提交
  4. 06 3月, 2019 1 次提交
  5. 28 2月, 2019 1 次提交
  6. 26 2月, 2019 1 次提交
    • C
      drm/i915: Replace global_seqno with a hangcheck heartbeat seqno · 89531e7d
      Chris Wilson 提交于
      To determine whether an engine has 'stuck', we simply check whether or
      not is still on the same seqno for several seconds. To keep this simple
      mechanism intact over the loss of a global seqno, we can simply add a
      new global heartbeat seqno instead. As we cannot know the sequence in
      which requests will then be completed, we use a primitive random number
      generator instead (with a cycle long enough to not matter over an
      interval of a few thousand requests between hangcheck samples).
      
      The alternative to using a dedicated seqno on every request is to issue
      a heartbeat request and query its progress through the system. Sadly
      this requires us to reduce struct_mutex so that we can issue requests
      without requiring that bkl.
      
      v2: And without the extra CS_STALL for the hangcheck seqno -- we don't
      need strict serialisation with what comes later, we just need to be sure
      we don't write the hangcheck seqno before our batch is flushed.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190226094922.31617-1-chris@chris-wilson.co.uk
      89531e7d
  7. 21 2月, 2019 1 次提交
  8. 13 2月, 2019 1 次提交
  9. 09 2月, 2019 2 次提交
  10. 08 2月, 2019 1 次提交
  11. 06 2月, 2019 2 次提交
  12. 30 1月, 2019 2 次提交
    • C
      drm/i915: Drop fake breadcrumb irq · 789659f4
      Chris Wilson 提交于
      Missed breadcrumb detection is defunct due to the tight coupling with
      dma_fence signaling and the myriad ways we may signal fences from
      everywhere but from an interrupt, i.e. we frequently signal a fence
      before we even see its interrupt. This means that even if we miss an
      interrupt for a fence, it still is signaled before our breadcrumb
      hangcheck fires, so simplify the breadcrumb hangchecking by moving it
      into the GPU hangcheck and forgo fake interrupts.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190129205230.19056-3-chris@chris-wilson.co.uk
      789659f4
    • C
      drm/i915: Replace global breadcrumbs with per-context interrupt tracking · 52c0fdb2
      Chris Wilson 提交于
      A few years ago, see commit 688e6c72 ("drm/i915: Slaughter the
      thundering i915_wait_request herd"), the issue of handling multiple
      clients waiting in parallel was brought to our attention. The
      requirement was that every client should be woken immediately upon its
      request being signaled, without incurring any cpu overhead.
      
      To handle certain fragility of our hw meant that we could not do a
      simple check inside the irq handler (some generations required almost
      unbounded delays before we could be sure of seqno coherency) and so
      request completion checking required delegation.
      
      Before commit 688e6c72, the solution was simple. Every client
      waiting on a request would be woken on every interrupt and each would do
      a heavyweight check to see if their request was complete. Commit
      688e6c72 introduced an rbtree so that only the earliest waiter on
      the global timeline would woken, and would wake the next and so on.
      (Along with various complications to handle requests being reordered
      along the global timeline, and also a requirement for kthread to provide
      a delegate for fence signaling that had no process context.)
      
      The global rbtree depends on knowing the execution timeline (and global
      seqno). Without knowing that order, we must instead check all contexts
      queued to the HW to see which may have advanced. We trim that list by
      only checking queued contexts that are being waited on, but still we
      keep a list of all active contexts and their active signalers that we
      inspect from inside the irq handler. By moving the waiters onto the fence
      signal list, we can combine the client wakeup with the dma_fence
      signaling (a dramatic reduction in complexity, but does require the HW
      being coherent, the seqno must be visible from the cpu before the
      interrupt is raised - we keep a timer backup just in case).
      
      Having previously fixed all the issues with irq-seqno serialisation (by
      inserting delays onto the GPU after each request instead of random delays
      on the CPU after each interrupt), we can rely on the seqno state to
      perfom direct wakeups from the interrupt handler. This allows us to
      preserve our single context switch behaviour of the current routine,
      with the only downside that we lose the RT priority sorting of wakeups.
      In general, direct wakeup latency of multiple clients is about the same
      (about 10% better in most cases) with a reduction in total CPU time spent
      in the waiter (about 20-50% depending on gen). Average herd behaviour is
      improved, but at the cost of not delegating wakeups on task_prio.
      
      v2: Capture fence signaling state for error state and add comments to
      warm even the most cold of hearts.
      v3: Check if the request is still active before busywaiting
      v4: Reduce the amount of pointer misdirection with list_for_each_safe
      and using a local i915_request variable inside the loops
      v5: Add a missing pluralisation to a purely informative selftest message.
      
      References: 688e6c72 ("drm/i915: Slaughter the thundering i915_wait_request herd")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190129205230.19056-2-chris@chris-wilson.co.uk
      52c0fdb2
  13. 29 1月, 2019 1 次提交
  14. 28 1月, 2019 1 次提交
  15. 25 1月, 2019 1 次提交
  16. 24 1月, 2019 1 次提交
  17. 23 1月, 2019 2 次提交
  18. 18 1月, 2019 1 次提交
  19. 17 1月, 2019 2 次提交
  20. 15 1月, 2019 8 次提交
  21. 10 1月, 2019 2 次提交
  22. 08 1月, 2019 1 次提交
  23. 07 1月, 2019 1 次提交
  24. 02 1月, 2019 1 次提交
  25. 28 12月, 2018 1 次提交