1. 27 3月, 2017 4 次提交
  2. 24 3月, 2017 1 次提交
  3. 21 3月, 2017 3 次提交
  4. 20 3月, 2017 1 次提交
  5. 17 3月, 2017 4 次提交
  6. 16 3月, 2017 1 次提交
    • C
      drm/i915/scheduler: emulate a scheduler for guc · 31de7350
      Chris Wilson 提交于
      This emulates execlists on top of the GuC in order to defer submission of
      requests to the hardware. This deferral allows time for high priority
      requests to gazump their way to the head of the queue, however it nerfs
      the GuC by converting it back into a simple execlist (where the CPU has
      to wake up after every request to feed new commands into the GuC).
      
      v2: Drop hack status - though iirc there is still a lockdep inversion
      between fence and engine->timeline->lock (which is impossible as the
      nesting only occurs on different fences - hopefully just requires some
      judicious lockdep annotation)
      v3: Apply lockdep nesting to enabling signaling on the request, using
      the pattern we already have in __i915_gem_request_submit();
      v4: Replaying requests after a hang also now needs the timeline
      spinlock, to disable the interrupts at least
      v5: Hold wq lock for completeness, and emit a tracepoint for enabling signal
      v6: Reorder interrupt checking for a happier gcc.
      v7: Only signal the tasklet after a user-interrupt if using guc scheduling
      v8: Restore lost update of rq through the i915_guc_irq_handler (Tvrtko)
      v9: Avoid re-initialising the engine->irq_tasklet from inside a reset
      v10: Hook up the execlists-style tracepoints
      v11: Clear the execlists irq_posted bit after taking over the interrupt/tasklet
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170316125619.6856-1-chris@chris-wilson.co.ukReviewed-by: NMichał Winiarski <michal.winiarski@intel.com>
      31de7350
  7. 03 3月, 2017 3 次提交
  8. 27 2月, 2017 1 次提交
  9. 24 2月, 2017 1 次提交
  10. 21 2月, 2017 2 次提交
  11. 20 2月, 2017 1 次提交
  12. 17 2月, 2017 2 次提交
  13. 16 2月, 2017 2 次提交
  14. 15 2月, 2017 1 次提交
  15. 14 2月, 2017 1 次提交
    • T
      drm/i915: Emit to ringbuffer directly · 73dec95e
      Tvrtko Ursulin 提交于
      This removes the usage of intel_ring_emit in favour of
      directly writing to the ring buffer.
      
      intel_ring_emit was preventing the compiler for optimising
      fetch and increment of the current ring buffer pointer and
      therefore generating very verbose code for every write.
      
      It had no useful purpose since all ringbuffer operations
      are started and ended with intel_ring_begin and
      intel_ring_advance respectively, with no bail out in the
      middle possible, so it is fine to increment the tail in
      intel_ring_begin and let the code manage the pointer
      itself.
      
      Useless instruction removal amounts to approximately
      two and half kilobytes of saved text on my build.
      
      Not sure if this has any measurable performance
      implications but executing a ton of useless instructions
      on fast paths cannot be good.
      
      v2:
       * Change return from intel_ring_begin to error pointer by
         popular demand.
       * Move tail increment to intel_ring_advance to enable some
         error checking.
      
      v3:
       * Move tail advance back into intel_ring_begin.
       * Rebase and tidy.
      
      v4:
       * Complete rebase after a few months since v3.
      
      v5:
       * Remove unecessary cast and fix !debug compile. (Chris Wilson)
      
      v6:
       * Make intel_ring_offset take request as well.
       * Fix recording of request postfix plus a sprinkle of asserts.
         (Chris Wilson)
      
      v7:
       * Use intel_ring_offset to get the postfix. (Chris Wilson)
       * Convert GVT code as well.
      
      v8:
       * Rename *out++ to *cs++.
      
      v9:
       * Fix GVT out to cs conversion in GVT.
      
      v10:
       * Rebase for new intel_ring_begin in selftests.
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Zhi Wang <zhi.a.wang@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Acked-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170214113242.29241-1-tvrtko.ursulin@linux.intel.com
      73dec95e
  16. 11 2月, 2017 1 次提交
  17. 10 2月, 2017 2 次提交
  18. 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
  19. 07 2月, 2017 1 次提交
  20. 06 2月, 2017 2 次提交
  21. 01 2月, 2017 2 次提交
  22. 30 1月, 2017 2 次提交
  23. 25 1月, 2017 1 次提交