drm/i915: Serialise i915_active_fence_set() with itselfThe expected downside to commit 58b4c1a07ada ("drm/i915: Reduce nestedprepare_remote_context() to a trylock") was that it would need to retur
drm/i915: Serialise i915_active_fence_set() with itselfThe expected downside to commit 58b4c1a07ada ("drm/i915: Reduce nestedprepare_remote_context() to a trylock") was that it would need to return-EAGAIN to userspace in order to resolve potential mutex inversion. Suchan unsightly round trip is unnecessary if we could atomically insert abarrier into the i915_active_fence, so make it happen.Currently, we use the timeline->mutex (or some other named outer lock)to order insertion into the i915_active_fence (and so individual nodesof i915_active). Inside __i915_active_fence_set, we only need thenserialise with the interrupt handler in order to claim the timeline forourselves.However, if we remove the outer lock, we need to ensure the order isintact between not only multiple threads trying to insert themselvesinto the timeline, but also with the interrupt handler completing theprevious occupant. We use xchg() on insert so that we have an orderedsequence of insertions (and each caller knows the previous fence onwhich to wait, preserving the chain of all fences in the timeline), butwe then have to cmpxchg() in the interrupt handler to avoid overwritingthe new occupant. The only nasty side-effect is having to temporarilystrip off the RCU-annotations to apply the atomic operations, otherwisethe rules are much more conventional!Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112402Fixes: 58b4c1a07ada ("drm/i915: Reduce nested prepare_remote_context() to a trylock")Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>Link: https://patchwork.freedesktop.org/patch/msgid/20191127134527.3438410-1-chris@chris-wilson.co.uk
show more ...
drm/i915: make more headers self-containedThe headers in the gem/selftests/, gt/selftests, gvt/, selftests/directories have never been compile-tested, but it would be possibleto make them self-co
drm/i915: make more headers self-containedThe headers in the gem/selftests/, gt/selftests, gvt/, selftests/directories have never been compile-tested, but it would be possibleto make them self-contained.This commit only addresses missing <linux/types.h> and forwardstruct declarations.Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>Link: https://patchwork.freedesktop.org/patch/msgid/20191108094142.25942-1-yamada.masahiro@socionext.com
drm/i915: Coordinate i915_active with its own mutexForgo the struct_mutex serialisation for i915_active, and interpose itsown mutex handling for active/retire.This is a multi-layered sleight-of-
drm/i915: Coordinate i915_active with its own mutexForgo the struct_mutex serialisation for i915_active, and interpose itsown mutex handling for active/retire.This is a multi-layered sleight-of-hand. First, we had to ensure that noactive/retire callbacks accidentally inverted the mutex ordering rules,nor assumed that they were themselves serialised by struct_mutex. Morechallenging though, is the rule over updating elements of the activerbtree. Instead of the whole i915_active now being serialised bystruct_mutex, allocations/rotations of the tree are serialised by thei915_active.mutex and individual nodes are serialised by the callerusing the i915_timeline.mutex (we need to use nested spinlocks tointeract with the dma_fence callback lists).The pain point here is that instead of a single mutex around execbuf, wenow have to take a mutex for active tracker (one for each vma, context,etc) and a couple of spinlocks for each fence update. The improvement infine grained locking allowing for multiple concurrent clients(eventually!) should be worth it in typical loads.v2: Add some comments that barely elucidate anything :(Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>Link: https://patchwork.freedesktop.org/patch/msgid/20191004134015.13204-6-chris@chris-wilson.co.uk
drm/i915: Markup expected timeline locks for i915_activeAs every i915_active_request should be serialised by a dedicated lock,i915_active consists of a tree of locks; one for each node. Markup up
drm/i915: Markup expected timeline locks for i915_activeAs every i915_active_request should be serialised by a dedicated lock,i915_active consists of a tree of locks; one for each node. Markup upthe i915_active_request with what lock is supposed to be guarding it sothat we can verify that the serialised updated are indeed serialised.Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>Link: https://patchwork.freedesktop.org/patch/msgid/20190816121000.8507-2-chris@chris-wilson.co.uk
drm/i915: Rename i915_timeline to intel_timeline and move under gtMove all timeline code under gt and rename to intel_gt prefix.Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>Suggested-
drm/i915: Rename i915_timeline to intel_timeline and move under gtMove all timeline code under gt and rename to intel_gt prefix.Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>Link: https://patchwork.freedesktop.org/patch/msgid/20190621070811.7006-32-tvrtko.ursulin@linux.intel.com