1. 31 3月, 2017 1 次提交
  2. 30 3月, 2017 1 次提交
  3. 21 3月, 2017 1 次提交
  4. 17 3月, 2017 1 次提交
  5. 03 3月, 2017 2 次提交
  6. 02 3月, 2017 4 次提交
  7. 28 2月, 2017 1 次提交
    • C
      drm/i915: Signal first fence from irq handler if complete · 56299fb7
      Chris Wilson 提交于
      As execlists and other non-semaphore multi-engine devices coordinate
      between engines using interrupts, we can shave off a few 10s of
      microsecond of scheduling latency by doing the fence signaling from the
      interrupt as opposed to a RT kthread. (Realistically the delay adds
      about 1% to an individual cross-engine workload.) We only signal the
      first fence in order to limit the amount of work we move into the
      interrupt handler. We also have to remember that our breadcrumbs may be
      unordered with respect to the interrupt and so we still require the
      waiter process to perform some heavyweight coherency fixups, as well as
      traversing the tree of waiters.
      
      v2: No need for early exit in irq handler - it breaks the flow between
      patches and prevents the tracepoint
      v3: Restore rcu hold across irq signaling of request
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170227205850.2828-2-chris@chris-wilson.co.uk
      56299fb7
  8. 23 2月, 2017 12 次提交
  9. 21 2月, 2017 2 次提交
  10. 17 2月, 2017 1 次提交
  11. 16 2月, 2017 1 次提交
  12. 14 2月, 2017 2 次提交
    • 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
    • C
      drm/i915: Add selftests for i915_gem_request · c835c550
      Chris Wilson 提交于
      Simple starting point for adding seltests for i915_gem_request, first
      mock a device (with engines and contexts) that allows us to construct
      and execute a request, along with waiting for the request to complete.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170213171558.20942-10-chris@chris-wilson.co.uk
      c835c550
  13. 09 2月, 2017 1 次提交
  14. 16 1月, 2017 1 次提交
  15. 11 1月, 2017 1 次提交
    • C
      drm/i915: Add a sanity check that no request is submitted in the middle · c781c978
      Chris Wilson 提交于
      It is an error to start a new request on the same timeline (ringbuffer)
      as the current one before the current is submitted. If there are two
      requests emitting to the ringbuffer at the same time, the operation is
      undefined. We can catch this by checking for the timeline having a later
      seqno than ours when we come to submit our request.
      
      Currently we have this check at the end of __i915_add_request, but
      having an early check as well isolates a failure in the caller versus a
      failure in sealing the request (i.e. from inside __i915_add_request
      itself). For example, CI is currently tripping over this late assertion
      on ctg/ilk:
      
      [  100.329399] [IGT] gem_cs_tlb: starting subtest basic-default
      [  100.336333] ------------[ cut here ]------------
      [  100.336341] kernel BUG at drivers/gpu/drm/i915/i915_gem_request.c:908!
      [  100.336347] invalid opcode: 0000 [#1] PREEMPT SMP
      [  100.336351] Modules linked in: snd_hda_intel i915 snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core snd_pcm coretemp mei_me lpc_ich mei e1000e ptp pps_core [last unloaded: i915]
      [  100.336373] CPU: 0 PID: 6308 Comm: gem_cs_tlb Tainted: G     U          4.10.0-rc3-CI-CI_DRM_2045+ #1
      [  100.336380] Hardware name: LENOVO 7465CTO/7465CTO, BIOS 6DET44WW (2.08 ) 04/22/2009
      [  100.336386] task: ffff88012b738040 task.stack: ffffc90000560000
      [  100.336441] RIP: 0010:__i915_add_request+0x4aa/0x510 [i915]
      [  100.336445] RSP: 0018:ffffc90000563ac0 EFLAGS: 00010212
      [  100.336451] RAX: 0000000000005d52 RBX: ffff880133bb84c0 RCX: 0000000000000001
      [  100.336456] RDX: 0000000080000001 RSI: ffff88012b738860 RDI: 00000000ffffffff
      [  100.336461] RBP: ffffc90000563b00 R08: ffff880133bb8780 R09: 0000000000000000
      [  100.336466] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88012f53d950
      [  100.336472] R13: ffff88012a2b0af8 R14: ffff88012a5b0008 R15: ffff88012f53d960
      [  100.336477] FS:  00007f0d19da38c0(0000) GS:ffff88013bc00000(0000) knlGS:0000000000000000
      [  100.336483] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  100.336488] CR2: 00007f0d17706000 CR3: 000000012aa3e000 CR4: 00000000000406f0
      [  100.336496] Call Trace:
      [  100.336527]  i915_gem_switch_to_kernel_context+0x131/0x1b0 [i915]
      [  100.336559]  i915_gem_evict_vm+0x202/0x2b0 [i915]
      [  100.336590]  i915_gem_execbuffer_reserve.isra.9+0x3ae/0x440 [i915]
      [  100.336623]  i915_gem_do_execbuffer.isra.15+0x6d9/0x1b20 [i915]
      [  100.336656]  i915_gem_execbuffer2+0xc0/0x250 [i915]
      [  100.336666]  drm_ioctl+0x200/0x450
      [  100.336697]  ? i915_gem_execbuffer+0x330/0x330 [i915]
      [  100.336708]  do_vfs_ioctl+0x90/0x6e0
      [  100.336716]  ? up_read+0x1a/0x40
      [  100.336723]  ? trace_hardirqs_on_caller+0x122/0x1b0
      [  100.336730]  SyS_ioctl+0x3c/0x70
      [  100.336738]  entry_SYSCALL_64_fastpath+0x1c/0xb1
      [  100.336745] RIP: 0033:0x7f0d187cb357
      [  100.336750] RSP: 002b:00007ffe0b2f7c28 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      [  100.336761] RAX: ffffffffffffffda RBX: 00007ffe0b2f7d60 RCX: 00007f0d187cb357
      [  100.336768] RDX: 00007ffe0b2f7d00 RSI: 0000000040406469 RDI: 0000000000000003
      [  100.336775] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000022
      [  100.336782] R10: 0000000000000007 R11: 0000000000000246 R12: 0000000000000002
      [  100.336789] R13: 0000000000419101 R14: 00007ffe0b2f7d60 R15: 00007ffe0b2f7d50
      [  100.336797] Code: 5f 74 1e e9 d4 fb ff ff e8 bc 1e 9c e0 e9 ae fb ff ff 4c 89 e7 e8 77 22 fd ff e9 88 fd ff ff 0f 0b e8 a3 1e 9c e0 e9 b1 fb ff ff <0f> 0b 0f 0b e8 fd af ab e0 85 c0 75 c2 48 c7 c2 80 2c 71 a0 be
      [  100.336877] RIP: __i915_add_request+0x4aa/0x510 [i915] RSP: ffffc90000563ac0
      [  100.336886] ---[ end trace 22b36545479e5eb7 ]---
      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: http://patchwork.freedesktop.org/patch/msgid/20170111140858.1922-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      c781c978
  16. 19 12月, 2016 2 次提交
    • C
      drm/i915: Swap if(enable_execlists) in i915_gem_request_alloc for a vfunc · f73e7399
      Chris Wilson 提交于
      A fairly trivial move of a matching pair of routines (for preparing a
      request for construction) onto an engine vfunc. The ulterior motive is
      to be able to create a mock request implementation.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161218153724.8439-7-chris@chris-wilson.co.uk
      f73e7399
    • C
      drm/i915: Unify active context tracking between legacy/execlists/guc · e8a9c58f
      Chris Wilson 提交于
      The requests conversion introduced a nasty bug where we could generate a
      new request in the middle of constructing a request if we needed to idle
      the system in order to evict space for a context. The request to idle
      would be executed (and waited upon) before the current one, creating a
      minor havoc in the seqno accounting, as we will consider the current
      request to already be completed (prior to deferred seqno assignment) but
      ring->last_retired_head would have been updated and still could allow
      us to overwrite the current request before execution.
      
      We also employed two different mechanisms to track the active context
      until it was switched out. The legacy method allowed for waiting upon an
      active context (it could forcibly evict any vma, including context's),
      but the execlists method took a step backwards by pinning the vma for
      the entire active lifespan of the context (the only way to evict was to
      idle the entire GPU, not individual contexts). However, to circumvent
      the tricky issue of locking (i.e. we cannot take struct_mutex at the
      time of i915_gem_request_submit(), where we would want to move the
      previous context onto the active tracker and unpin it), we take the
      execlists approach and keep the contexts pinned until retirement.
      The benefit of the execlists approach, more important for execlists than
      legacy, was the reduction in work in pinning the context for each
      request - as the context was kept pinned until idle, it could short
      circuit the pinning for all active contexts.
      
      We introduce new engine vfuncs to pin and unpin the context
      respectively. The context is pinned at the start of the request, and
      only unpinned when the following request is retired (this ensures that
      the context is idle and coherent in main memory before we unpin it). We
      move the engine->last_context tracking into the retirement itself
      (rather than during request submission) in order to allow the submission
      to be reordered or unwound without undue difficultly.
      
      And finally an ulterior motive for unifying context handling was to
      prepare for mock requests.
      
      v2: Rename to last_retired_context, split out legacy_context tracking
      for MI_SET_CONTEXT.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161218153724.8439-3-chris@chris-wilson.co.uk
      e8a9c58f
  17. 05 12月, 2016 1 次提交
  18. 25 11月, 2016 5 次提交