Skip to content

K
Kernel

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

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 01 7月, 2013 1 次提交
    • B
      drm/i915: Fix context sizes on HSW · a0de80a0
      由 Ben Widawsky 提交于 
      With updates to the spec, we can actually see the context layout, and
how many dwords are allocated. That table suggests we need 70720 bytes
per HW context. Rounded up, this is 18 pages. Looking at what lives
after the current 4 pages we use, I can't see too much important (mostly
it's d3d related), but there are a couple of things which look scary. I
am hopeful this can explain some of our odd HSW failures.

v2: Make the context only 17 pages. The power context space isn't used
ever, and execlists aren't used in our driver, making the actual total
66944 bytes.

v3: Add a comment to the code. (Jesse & Paulo)
Reported-by: N"Azad, Vinit" <vinit.azad@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      a0de80a0
  3. 13 6月, 2013 2 次提交
  5. 01 6月, 2013 1 次提交
    • B
      drm/i915: context debug messages · bb036413
      由 Ben Widawsky 提交于 
      Add some debug messages to help figure out what goes wrong on context
initialization.

Later in the PPGTT series, I ended up having a lot of failures after
reset. In many cases it was extra difficult to debug because I hadn't
even realized that contexts failed to reinitialize after reset (again an
artifact of some later patches).

This fairly benign patch does help debug some potential issues which
arise later.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      bb036413
  7. 11 5月, 2013 1 次提交
  9. 06 5月, 2013 2 次提交
  11. 04 5月, 2013 1 次提交
  13. 01 5月, 2013 1 次提交
    • M
      drm/i915: reference count for i915_hw_contexts · dce3271b
      由 Mika Kuoppala 提交于 
      Enabling PPGTT and also the need to track which context was guilty of
gpu hang (arb robustness enabling) have put pressure for struct i915_hw_context
to be more than just a placeholder for hw context state.

In order to track object lifetime properly in a multi peer usage, add reference
counting for i915_hw_context.

v2: track i915_hw_context pointers instead of using ctx_ids
(from Chris Wilson)

v3 (Ben): Get rid of do_release() and handle refcounting more compactly.
(recommended by Chis)

v4: kref_* put inside static inlines (Daniel Vetter)
remove code duplication on freeing context (Chris Wilson)

v5: idr_remove and ctx->file_priv = NULL in destroy ioctl (Chris)
This actually will cause a problem if one destroys a context and later
refers to the idea of the context (multiple contexts may have the same
id, but only 1 will exist in the idr).

v6: Strip out the request related stuff. Reworded commit message.
Got rid of do_destroy and introduced i915_gem_context_release_handle,
suggested by Chris Wilson.

v7: idr_remove can't be called inside idr_for_each (Chris Wilson)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net> (v5)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> (v7)
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: Squash sob lines, the patch ping-ponged between Ben and Mika
a bit ...]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      dce3271b
  15. 18 4月, 2013 1 次提交
    • C
      drm/i915: Use MLC (l3$) for context objects · 4615d4c9
      由 Chris Wilson 提交于 
      Enabling context support increases SwapBuffers latency by about 20%
(measured on an i7-3720qm). We can offset that loss slightly by enabling
faster caching for the contexts. As they are not backed by any
particular cache (such as the sampler or render caches) our only option
is to select the generic mid-level cache. This reduces the latency of
the swap by about 5%.

Oddly this effect can be observed running smokin-guns on IVB at
1280x1024:
Using BLT copies for swaps: 151.67 fps
Using Render copies for swaps (unpatched):  141.70 fps
With contexts disabled: 150.23 fps
With contexts in L3$: 150.77 fps
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      4615d4c9
  17. 28 2月, 2013 1 次提交
  19. 15 2月, 2013 2 次提交
  21. 29 11月, 2012 1 次提交
    • C
      drm/i915: Preallocate next seqno before touching the ring · 9d773091
      由 Chris Wilson 提交于 
      Based on the work by Mika Kuoppala, we realised that we need to handle
seqno wraparound prior to committing our changes to the ring. The most
obvious point then is to grab the seqno inside intel_ring_begin(), and
then to reuse that seqno for all ring operations until the next request.
As intel_ring_begin() can fail, the callers must already be prepared to
handle such failure and so we can safely add further checks.

This patch looks like it should be split up into the interface
changes and the tweaks to move seqno wrapping from the execbuffer into
the core seqno increment. However, I found no easy way to break it into
incremental steps without introducing further broken behaviour.

v2: Mika found a silly mistake and a subtle error in the existing code;
inside i915_gem_retire_requests() we were resetting the sync_seqno of
the target ring based on the seqno from this ring - which are only
related by the order of their allocation, not retirement. Hence we were
applying the optimisation that the rings were synchronised too early,
fortunately the only real casualty there is the handling of seqno
wrapping.

v3: Do not forget to reset the sync_seqno upon module reinitialisation,
ala resume.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=863861
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> [v2]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      9d773091
  23. 12 11月, 2012 1 次提交
  25. 03 10月, 2012 1 次提交
  27. 02 10月, 2012 1 次提交
    • C
      drm/i915: Actually invalidate the TLB for the SandyBridge HW contexts w/a · ac82ea2e
      由 Chris Wilson 提交于 
      A side-effect of commit 7d54a904
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Aug 10 10:18:10 2012 +0100

    drm/i915: Apply post-sync write for pipe control invalidates

was that only a request to emit invalidate flush would result in the
TLB being invalidated (since it requires synchronisation and so incurs a
performance penalty). However, the stated w/a for hardware contexts is
that the TLBs must be invalidated prior to a MI_SET_CONTEXT, yet the w/a
itself did not request the TLBs to be invalidated...

Note this w/a does not prevent the hard system hang I experience when
using hw contexts (with rc6 enabled) on SNB GT1.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ac82ea2e
  29. 24 8月, 2012 1 次提交
  31. 06 8月, 2012 1 次提交
  33. 26 7月, 2012 2 次提交
  35. 25 7月, 2012 3 次提交
  37. 20 7月, 2012 1 次提交
  39. 30 6月, 2012 1 次提交
  41. 20 6月, 2012 6 次提交
  43. 18 6月, 2012 1 次提交
  45. 14 6月, 2012 7 次提交
    • B
      drm/i915: reset the GPU on context fini · 8e96d9c4
      由 Ben Widawsky 提交于 
      It's the only way we know how to make the GPU actually forget about the
default context.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      8e96d9c4
    • B
      drm/i915/context: create & destroy ioctls · 84624813
      由 Ben Widawsky 提交于 
      Add the interfaces to allow user space to create and destroy contexts.
Contexts are destroyed automatically if the file descriptor for the dri
device is closed.

Following convention as usual here causes checkpatch warnings.

v2: with is_initialized, no longer need to init at create
drop the context switch on create (daniel)

v3: Use interruptible lock (Chris)
return -ENODEV in !GEM case (Chris)
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      84624813
    • B
      drm/i915: use the default context · dfabbcb4
      由 Ben Widawsky 提交于 
      With the code to do HW context switches in place have the driver load the
default context for the render ring when the driver loads.

The default context will be an ever present context that is available to
switch to at any time for the given ring.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      dfabbcb4
    • B
      drm/i915: possibly invalidate TLB before context switch · 12b0286f
      由 Ben Widawsky 提交于 
      From http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol1_Part3.pdf

[DevSNB] If Flush TLB invalidation Mode is enabled it's the driver's
responsibility to invalidate the TLBs at least once after the previous
context switch after any GTT mappings changed (including new GTT
entries).  This can be done by a pipelined PIPE_CONTROL with TLB inv bit
set immediately before MI_SET_CONTEXT.

On GEN7 the invalidation mode is explicitly set, but this appears to be
lacking for GEN6. Since I don't know the history on this, I've decided
to dynamically read the value at ring init time, and use that value
throughout.

v2: better comment (daniel)
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      12b0286f
    • B
      drm/i915: Ivybridge MI_ARB_ON_OFF context w/a · e37ec39b
      由 Ben Widawsky 提交于 
      The workaround itself applies to gen7 only (according to the docs) and
as Eric Anholt points out shouldn't be required since we don't use HW
scheduling features, and therefore arbitration. Though since it is a
small, and simple addition, and we don't really understand the issue,
just do it.

FWIW, I eventually want to play with some of the arbitration stuff, and
I'd hate to forget about this.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      e37ec39b
    • D
      drm/i915: ensure context objects are bound to the global gtt · 3af7b857
      由 Daniel Vetter 提交于 
      This way round we don't introduce and ugly layering violations and use
the interface as I planned to use it.
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3af7b857
    • B
      drm/i915: context switch implementation · e0556841
      由 Ben Widawsky 提交于 
      Implement the context switch code as well as the interfaces to do the
context switch. This patch also doesn't match 1:1 with the RFC patches.
The main difference is that from Daniel's responses the last context
object is now stored instead of the last context. This aids in allows us
to free the context data structure, and context object independently.

There is room for optimization: this code will pin the context object
until the next context is active. The optimal way to do it is to
actually pin the object, move it to the active list, do the context
switch, and then unpin it. This allows the eviction code to actually
evict the context object if needed.

The context switch code is missing workarounds, they will be implemented
in future patches.

v2: actually do obj->dirty=1 in switch (daniel)
Modified comment around above
Remove flags to context switch (daniel)
Move mi_set_context code to i915_gem_context.c (daniel)
Remove seqno , use lazy request instead (daniel)

v3: use i915_gem_request_next_seqno instead of
      outstanding_lazy_request (Daniel)
remove id's from trace events (Daniel)
Put the context BO in the instruction domain (Daniel)
Don't unref the BO is context switch fails (Chris)
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      e0556841