2010-08-07 14:01:23 +04:00
|
|
|
/*
|
|
|
|
* Copyright © 2008-2010 Intel Corporation
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
* copy of this software and associated documentation files (the "Software"),
|
|
|
|
* to deal in the Software without restriction, including without limitation
|
|
|
|
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
|
|
|
|
* and/or sell copies of the Software, and to permit persons to whom the
|
|
|
|
* Software is furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice (including the next
|
|
|
|
* paragraph) shall be included in all copies or substantial portions of the
|
|
|
|
* Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
|
|
|
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
|
|
|
|
* IN THE SOFTWARE.
|
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* Eric Anholt <eric@anholt.net>
|
|
|
|
* Chris Wilson <chris@chris-wilson.co.uuk>
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
2012-10-02 21:01:07 +04:00
|
|
|
#include <drm/i915_drm.h>
|
2014-01-20 14:17:37 +04:00
|
|
|
|
2019-05-28 12:29:49 +03:00
|
|
|
#include "gem/i915_gem_context.h"
|
2019-10-04 16:40:06 +03:00
|
|
|
#include "gt/intel_gt_requests.h"
|
2019-05-28 12:29:49 +03:00
|
|
|
|
2014-01-20 14:17:37 +04:00
|
|
|
#include "i915_drv.h"
|
2011-02-03 14:57:46 +03:00
|
|
|
#include "i915_trace.h"
|
2010-08-07 14:01:23 +04:00
|
|
|
|
2017-10-12 15:57:26 +03:00
|
|
|
I915_SELFTEST_DECLARE(static struct igt_evict_ctl {
|
|
|
|
bool fail_if_busy:1;
|
|
|
|
} igt_evict_ctl;)
|
|
|
|
|
2019-10-04 16:40:06 +03:00
|
|
|
static int ggtt_flush(struct intel_gt *gt)
|
drm/i915: Eliminate lots of iterations over the execobjects array
The major scaling bottleneck in execbuffer is the processing of the
execobjects. Creating an auxiliary list is inefficient when compared to
using the execobject array we already have allocated.
Reservation is then split into phases. As we lookup up the VMA, we
try and bind it back into active location. Only if that fails, do we add
it to the unbound list for phase 2. In phase 2, we try and add all those
objects that could not fit into their previous location, with fallback
to retrying all objects and evicting the VM in case of severe
fragmentation. (This is the same as before, except that phase 1 is now
done inline with looking up the VMA to avoid an iteration over the
execobject array. In the ideal case, we eliminate the separate reservation
phase). During the reservation phase, we only evict from the VM between
passes (rather than currently as we try to fit every new VMA). In
testing with Unreal Engine's Atlantis demo which stresses the eviction
logic on gen7 class hardware, this speed up the framerate by a factor of
2.
The second loop amalgamation is between move_to_gpu and move_to_active.
As we always submit the request, even if incomplete, we can use the
current request to track active VMA as we perform the flushes and
synchronisation required.
The next big advancement is to avoid copying back to the user any
execobjects and relocations that are not changed.
v2: Add a Theory of Operation spiel.
v3: Fall back to slow relocations in preparation for flushing userptrs.
v4: Document struct members, factor out eb_validate_vma(), add a few
more comments to explain some magic and hide other magic behind macros.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2017-06-16 17:05:19 +03:00
|
|
|
{
|
2019-03-08 12:36:57 +03:00
|
|
|
/*
|
|
|
|
* Not everything in the GGTT is tracked via vma (otherwise we
|
drm/i915: Eliminate lots of iterations over the execobjects array
The major scaling bottleneck in execbuffer is the processing of the
execobjects. Creating an auxiliary list is inefficient when compared to
using the execobject array we already have allocated.
Reservation is then split into phases. As we lookup up the VMA, we
try and bind it back into active location. Only if that fails, do we add
it to the unbound list for phase 2. In phase 2, we try and add all those
objects that could not fit into their previous location, with fallback
to retrying all objects and evicting the VM in case of severe
fragmentation. (This is the same as before, except that phase 1 is now
done inline with looking up the VMA to avoid an iteration over the
execobject array. In the ideal case, we eliminate the separate reservation
phase). During the reservation phase, we only evict from the VM between
passes (rather than currently as we try to fit every new VMA). In
testing with Unreal Engine's Atlantis demo which stresses the eviction
logic on gen7 class hardware, this speed up the framerate by a factor of
2.
The second loop amalgamation is between move_to_gpu and move_to_active.
As we always submit the request, even if incomplete, we can use the
current request to track active VMA as we perform the flushes and
synchronisation required.
The next big advancement is to avoid copying back to the user any
execobjects and relocations that are not changed.
v2: Add a Theory of Operation spiel.
v3: Fall back to slow relocations in preparation for flushing userptrs.
v4: Document struct members, factor out eb_validate_vma(), add a few
more comments to explain some magic and hide other magic behind macros.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2017-06-16 17:05:19 +03:00
|
|
|
* could evict as required with minimal stalling) so we are forced
|
|
|
|
* to idle the GPU and explicitly retire outstanding requests in
|
|
|
|
* the hopes that we can then remove contexts and the like only
|
|
|
|
* bound by their active reference.
|
|
|
|
*/
|
2019-10-04 16:40:06 +03:00
|
|
|
return intel_gt_wait_for_idle(gt, MAX_SCHEDULE_TIMEOUT);
|
drm/i915: Eliminate lots of iterations over the execobjects array
The major scaling bottleneck in execbuffer is the processing of the
execobjects. Creating an auxiliary list is inefficient when compared to
using the execobject array we already have allocated.
Reservation is then split into phases. As we lookup up the VMA, we
try and bind it back into active location. Only if that fails, do we add
it to the unbound list for phase 2. In phase 2, we try and add all those
objects that could not fit into their previous location, with fallback
to retrying all objects and evicting the VM in case of severe
fragmentation. (This is the same as before, except that phase 1 is now
done inline with looking up the VMA to avoid an iteration over the
execobject array. In the ideal case, we eliminate the separate reservation
phase). During the reservation phase, we only evict from the VM between
passes (rather than currently as we try to fit every new VMA). In
testing with Unreal Engine's Atlantis demo which stresses the eviction
logic on gen7 class hardware, this speed up the framerate by a factor of
2.
The second loop amalgamation is between move_to_gpu and move_to_active.
As we always submit the request, even if incomplete, we can use the
current request to track active VMA as we perform the flushes and
synchronisation required.
The next big advancement is to avoid copying back to the user any
execobjects and relocations that are not changed.
v2: Add a Theory of Operation spiel.
v3: Fall back to slow relocations in preparation for flushing userptrs.
v4: Document struct members, factor out eb_validate_vma(), add a few
more comments to explain some magic and hide other magic behind macros.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2017-06-16 17:05:19 +03:00
|
|
|
}
|
|
|
|
|
2010-08-07 14:01:24 +04:00
|
|
|
static bool
|
2016-12-22 11:36:29 +03:00
|
|
|
mark_free(struct drm_mm_scan *scan,
|
|
|
|
struct i915_vma *vma,
|
|
|
|
unsigned int flags,
|
|
|
|
struct list_head *unwind)
|
2010-08-07 14:01:23 +04:00
|
|
|
{
|
2016-08-04 18:32:30 +03:00
|
|
|
if (i915_vma_is_pinned(vma))
|
2012-04-24 18:47:30 +04:00
|
|
|
return false;
|
|
|
|
|
2017-06-15 11:14:35 +03:00
|
|
|
list_add(&vma->evict_link, unwind);
|
2016-12-22 11:36:29 +03:00
|
|
|
return drm_mm_scan_add_block(scan, &vma->node);
|
2010-08-07 14:01:23 +04:00
|
|
|
}
|
|
|
|
|
2014-01-30 01:07:11 +04:00
|
|
|
/**
|
|
|
|
* i915_gem_evict_something - Evict vmas to make room for binding a new one
|
|
|
|
* @vm: address space to evict from
|
2015-01-05 16:36:59 +03:00
|
|
|
* @min_size: size of the desired free space
|
2014-01-30 01:07:11 +04:00
|
|
|
* @alignment: alignment constraint of the desired free space
|
2019-09-09 15:40:52 +03:00
|
|
|
* @color: color for the desired space
|
2015-01-05 16:36:59 +03:00
|
|
|
* @start: start (inclusive) of the range from which to evict objects
|
|
|
|
* @end: end (exclusive) of the range from which to evict objects
|
|
|
|
* @flags: additional flags to control the eviction algorithm
|
2014-01-30 01:07:11 +04:00
|
|
|
*
|
|
|
|
* This function will try to evict vmas until a free space satisfying the
|
|
|
|
* requirements is found. Callers must check first whether any such hole exists
|
|
|
|
* already before calling this function.
|
|
|
|
*
|
|
|
|
* This function is used by the object/vma binding code.
|
|
|
|
*
|
2015-03-18 16:47:59 +03:00
|
|
|
* Since this function is only used to free up virtual address space it only
|
|
|
|
* ignores pinned vmas, and not object where the backing storage itself is
|
|
|
|
* pinned. Hence obj->pages_pin_count does not protect against eviction.
|
|
|
|
*
|
2014-01-30 01:07:11 +04:00
|
|
|
* To clarify: This is for freeing up virtual address space, not for freeing
|
|
|
|
* memory in e.g. the shrinker.
|
|
|
|
*/
|
2010-08-07 14:01:23 +04:00
|
|
|
int
|
2016-08-04 18:32:18 +03:00
|
|
|
i915_gem_evict_something(struct i915_address_space *vm,
|
2016-08-04 18:32:22 +03:00
|
|
|
u64 min_size, u64 alignment,
|
2019-09-09 15:40:52 +03:00
|
|
|
unsigned long color,
|
2016-08-04 18:32:22 +03:00
|
|
|
u64 start, u64 end,
|
2014-02-14 17:01:11 +04:00
|
|
|
unsigned flags)
|
2010-08-07 14:01:23 +04:00
|
|
|
{
|
2016-12-22 11:36:29 +03:00
|
|
|
struct drm_mm_scan scan;
|
2016-08-04 18:32:17 +03:00
|
|
|
struct list_head eviction_list;
|
|
|
|
struct i915_vma *vma, *next;
|
2016-12-22 11:36:36 +03:00
|
|
|
struct drm_mm_node *node;
|
2017-02-03 00:04:38 +03:00
|
|
|
enum drm_mm_insert_mode mode;
|
2019-01-28 13:23:52 +03:00
|
|
|
struct i915_vma *active;
|
2016-08-04 18:32:17 +03:00
|
|
|
int ret;
|
2010-08-07 14:01:23 +04:00
|
|
|
|
drm/i915: Pull i915_vma_pin under the vm->mutex
Replace the struct_mutex requirement for pinning the i915_vma with the
local vm->mutex instead. Note that the vm->mutex is tainted by the
shrinker (we require unbinding from inside fs-reclaim) and so we cannot
allocate while holding that mutex. Instead we have to preallocate
workers to do allocate and apply the PTE updates after we have we
reserved their slot in the drm_mm (using fences to order the PTE writes
with the GPU work and with later unbind).
In adding the asynchronous vma binding, one subtle requirement is to
avoid coupling the binding fence into the backing object->resv. That is
the asynchronous binding only applies to the vma timeline itself and not
to the pages as that is a more global timeline (the binding of one vma
does not need to be ordered with another vma, nor does the implicit GEM
fencing depend on a vma, only on writes to the backing store). Keeping
the vma binding distinct from the backing store timelines is verified by
a number of async gem_exec_fence and gem_exec_schedule tests. The way we
do this is quite simple, we keep the fence for the vma binding separate
and only wait on it as required, and never add it to the obj->resv
itself.
Another consequence in reducing the locking around the vma is the
destruction of the vma is no longer globally serialised by struct_mutex.
A natural solution would be to add a kref to i915_vma, but that requires
decoupling the reference cycles, possibly by introducing a new
i915_mm_pages object that is own by both obj->mm and vma->pages.
However, we have not taken that route due to the overshadowing lmem/ttm
discussions, and instead play a series of complicated games with
trylocks to (hopefully) ensure that only one destruction path is called!
v2: Add some commentary, and some helpers to reduce patch churn.
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/20191004134015.13204-4-chris@chris-wilson.co.uk
2019-10-04 16:39:58 +03:00
|
|
|
lockdep_assert_held(&vm->mutex);
|
2016-08-04 18:32:18 +03:00
|
|
|
trace_i915_gem_evict(vm, min_size, alignment, flags);
|
2011-02-03 14:57:46 +03:00
|
|
|
|
2010-08-07 14:01:24 +04:00
|
|
|
/*
|
2019-01-28 13:23:52 +03:00
|
|
|
* The goal is to evict objects and amalgamate space in rough LRU order.
|
|
|
|
* Since both active and inactive objects reside on the same list,
|
|
|
|
* in a mix of creation and last scanned order, as we process the list
|
|
|
|
* we sort it into inactive/active, which keeps the active portion
|
|
|
|
* in a rough MRU order.
|
2010-08-07 14:01:24 +04:00
|
|
|
*
|
|
|
|
* The retirement sequence is thus:
|
2019-01-28 13:23:52 +03:00
|
|
|
* 1. Inactive objects (already retired, random order)
|
|
|
|
* 2. Active objects (will stall on unbinding, oldest scanned first)
|
2010-08-07 14:01:24 +04:00
|
|
|
*/
|
2017-02-03 00:04:38 +03:00
|
|
|
mode = DRM_MM_INSERT_BEST;
|
|
|
|
if (flags & PIN_HIGH)
|
|
|
|
mode = DRM_MM_INSERT_HIGH;
|
|
|
|
if (flags & PIN_MAPPABLE)
|
|
|
|
mode = DRM_MM_INSERT_LOW;
|
2016-12-22 11:36:31 +03:00
|
|
|
drm_mm_scan_init_with_range(&scan, &vm->mm,
|
2019-09-09 15:40:52 +03:00
|
|
|
min_size, alignment, color,
|
2017-02-03 00:04:38 +03:00
|
|
|
start, end, mode);
|
2010-08-07 14:01:24 +04:00
|
|
|
|
2019-10-04 16:40:06 +03:00
|
|
|
intel_gt_retire_requests(vm->gt);
|
2019-10-04 16:40:04 +03:00
|
|
|
|
2016-08-04 18:32:17 +03:00
|
|
|
search_again:
|
2019-01-28 13:23:52 +03:00
|
|
|
active = NULL;
|
2016-08-04 18:32:17 +03:00
|
|
|
INIT_LIST_HEAD(&eviction_list);
|
2019-01-28 13:23:52 +03:00
|
|
|
list_for_each_entry_safe(vma, next, &vm->bound_list, vm_link) {
|
|
|
|
/*
|
|
|
|
* We keep this list in a rough least-recently scanned order
|
|
|
|
* of active elements (inactive elements are cheap to reap).
|
|
|
|
* New entries are added to the end, and we move anything we
|
|
|
|
* scan to the end. The assumption is that the working set
|
|
|
|
* of applications is either steady state (and thanks to the
|
|
|
|
* userspace bo cache it almost always is) or volatile and
|
|
|
|
* frequently replaced after a frame, which are self-evicting!
|
|
|
|
* Given that assumption, the MRU order of the scan list is
|
|
|
|
* fairly static, and keeping it in least-recently scan order
|
|
|
|
* is suitable.
|
|
|
|
*
|
|
|
|
* To notice when we complete one full cycle, we record the
|
|
|
|
* first active element seen, before moving it to the tail.
|
|
|
|
*/
|
|
|
|
if (i915_vma_is_active(vma)) {
|
|
|
|
if (vma == active) {
|
|
|
|
if (flags & PIN_NONBLOCK)
|
|
|
|
break;
|
|
|
|
|
|
|
|
active = ERR_PTR(-EAGAIN);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (active != ERR_PTR(-EAGAIN)) {
|
|
|
|
if (!active)
|
|
|
|
active = vma;
|
|
|
|
|
|
|
|
list_move_tail(&vma->vm_link, &vm->bound_list);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (mark_free(&scan, vma, flags, &eviction_list))
|
|
|
|
goto found;
|
|
|
|
}
|
2010-08-07 14:01:24 +04:00
|
|
|
|
|
|
|
/* Nothing found, clean up and bail out! */
|
2017-06-15 11:14:35 +03:00
|
|
|
list_for_each_entry_safe(vma, next, &eviction_list, evict_link) {
|
2016-12-22 11:36:29 +03:00
|
|
|
ret = drm_mm_scan_remove_block(&scan, &vma->node);
|
2010-08-07 14:01:24 +04:00
|
|
|
BUG_ON(ret);
|
|
|
|
}
|
|
|
|
|
2017-10-12 15:57:24 +03:00
|
|
|
/*
|
|
|
|
* Can we unpin some objects such as idle hw contents,
|
2016-08-04 18:32:17 +03:00
|
|
|
* or pending flips? But since only the GGTT has global entries
|
|
|
|
* such as scanouts, rinbuffers and contexts, we can skip the
|
|
|
|
* purge when inspecting per-process local address spaces.
|
2010-08-07 14:01:24 +04:00
|
|
|
*/
|
2016-08-04 18:32:17 +03:00
|
|
|
if (!i915_is_ggtt(vm) || flags & PIN_NONBLOCK)
|
2014-01-20 14:17:37 +04:00
|
|
|
return -ENOSPC;
|
2013-12-09 14:37:24 +04:00
|
|
|
|
2017-10-12 15:57:24 +03:00
|
|
|
/*
|
|
|
|
* Not everything in the GGTT is tracked via VMA using
|
|
|
|
* i915_vma_move_to_active(), otherwise we could evict as required
|
|
|
|
* with minimal stalling. Instead we are forced to idle the GPU and
|
|
|
|
* explicitly retire outstanding requests which will then remove
|
|
|
|
* the pinning for active objects such as contexts and ring,
|
|
|
|
* enabling us to evict them on the next iteration.
|
|
|
|
*
|
|
|
|
* To ensure that all user contexts are evictable, we perform
|
|
|
|
* a switch to the perma-pinned kernel context. This all also gives
|
|
|
|
* us a termination condition, when the last retired context is
|
|
|
|
* the kernel's there is no more we can evict.
|
|
|
|
*/
|
drm/i915: Invert the GEM wakeref hierarchy
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the heart of the driver. (The intent there is to push
global GEM decisions to the boundary as used by the GEM user interface.)
Now during request construction, each request is responsible via its
logical context to acquire a wakeref on each power domain it intends to
utilize. Currently, each request takes a wakeref on the engine(s) and
the engines themselves take a chipset wakeref. This gives us a
transition on each engine which we can extend if we want to insert more
powermangement control (such as soft rc6). The global GEM operations
that currently require a struct_mutex are reduced to listening to pm
events from the chipset GT wakeref. As we reduce the struct_mutex
requirement, these listeners should evaporate.
Perhaps the biggest immediate change is that this removes the
struct_mutex requirement around GT power management, allowing us greater
flexibility in request construction. Another important knock-on effect,
is that by tracking engine usage, we can insert a switch back to the
kernel context on that engine immediately, avoiding any extra delay or
inserting global synchronisation barriers. This makes tracking when an
engine and its associated contexts are idle much easier -- important for
when we forgo our assumed execution ordering and need idle barriers to
unpin used contexts. In the process, it means we remove a large chunk of
code whose only purpose was to switch back to the kernel context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190424200717.1686-5-chris@chris-wilson.co.uk
2019-04-24 23:07:17 +03:00
|
|
|
if (I915_SELFTEST_ONLY(igt_evict_ctl.fail_if_busy))
|
|
|
|
return -EBUSY;
|
2017-10-12 15:57:26 +03:00
|
|
|
|
2019-10-04 16:40:06 +03:00
|
|
|
ret = ggtt_flush(vm->gt);
|
drm/i915: Invert the GEM wakeref hierarchy
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the heart of the driver. (The intent there is to push
global GEM decisions to the boundary as used by the GEM user interface.)
Now during request construction, each request is responsible via its
logical context to acquire a wakeref on each power domain it intends to
utilize. Currently, each request takes a wakeref on the engine(s) and
the engines themselves take a chipset wakeref. This gives us a
transition on each engine which we can extend if we want to insert more
powermangement control (such as soft rc6). The global GEM operations
that currently require a struct_mutex are reduced to listening to pm
events from the chipset GT wakeref. As we reduce the struct_mutex
requirement, these listeners should evaporate.
Perhaps the biggest immediate change is that this removes the
struct_mutex requirement around GT power management, allowing us greater
flexibility in request construction. Another important knock-on effect,
is that by tracking engine usage, we can insert a switch back to the
kernel context on that engine immediately, avoiding any extra delay or
inserting global synchronisation barriers. This makes tracking when an
engine and its associated contexts are idle much easier -- important for
when we forgo our assumed execution ordering and need idle barriers to
unpin used contexts. In the process, it means we remove a large chunk of
code whose only purpose was to switch back to the kernel context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190424200717.1686-5-chris@chris-wilson.co.uk
2019-04-24 23:07:17 +03:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
2014-01-20 14:17:37 +04:00
|
|
|
|
drm/i915: Invert the GEM wakeref hierarchy
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the heart of the driver. (The intent there is to push
global GEM decisions to the boundary as used by the GEM user interface.)
Now during request construction, each request is responsible via its
logical context to acquire a wakeref on each power domain it intends to
utilize. Currently, each request takes a wakeref on the engine(s) and
the engines themselves take a chipset wakeref. This gives us a
transition on each engine which we can extend if we want to insert more
powermangement control (such as soft rc6). The global GEM operations
that currently require a struct_mutex are reduced to listening to pm
events from the chipset GT wakeref. As we reduce the struct_mutex
requirement, these listeners should evaporate.
Perhaps the biggest immediate change is that this removes the
struct_mutex requirement around GT power management, allowing us greater
flexibility in request construction. Another important knock-on effect,
is that by tracking engine usage, we can insert a switch back to the
kernel context on that engine immediately, avoiding any extra delay or
inserting global synchronisation barriers. This makes tracking when an
engine and its associated contexts are idle much easier -- important for
when we forgo our assumed execution ordering and need idle barriers to
unpin used contexts. In the process, it means we remove a large chunk of
code whose only purpose was to switch back to the kernel context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190424200717.1686-5-chris@chris-wilson.co.uk
2019-04-24 23:07:17 +03:00
|
|
|
cond_resched();
|
2016-08-04 18:32:17 +03:00
|
|
|
|
drm/i915: Invert the GEM wakeref hierarchy
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the heart of the driver. (The intent there is to push
global GEM decisions to the boundary as used by the GEM user interface.)
Now during request construction, each request is responsible via its
logical context to acquire a wakeref on each power domain it intends to
utilize. Currently, each request takes a wakeref on the engine(s) and
the engines themselves take a chipset wakeref. This gives us a
transition on each engine which we can extend if we want to insert more
powermangement control (such as soft rc6). The global GEM operations
that currently require a struct_mutex are reduced to listening to pm
events from the chipset GT wakeref. As we reduce the struct_mutex
requirement, these listeners should evaporate.
Perhaps the biggest immediate change is that this removes the
struct_mutex requirement around GT power management, allowing us greater
flexibility in request construction. Another important knock-on effect,
is that by tracking engine usage, we can insert a switch back to the
kernel context on that engine immediately, avoiding any extra delay or
inserting global synchronisation barriers. This makes tracking when an
engine and its associated contexts are idle much easier -- important for
when we forgo our assumed execution ordering and need idle barriers to
unpin used contexts. In the process, it means we remove a large chunk of
code whose only purpose was to switch back to the kernel context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190424200717.1686-5-chris@chris-wilson.co.uk
2019-04-24 23:07:17 +03:00
|
|
|
flags |= PIN_NONBLOCK;
|
|
|
|
goto search_again;
|
2010-08-07 14:01:24 +04:00
|
|
|
|
|
|
|
found:
|
2010-09-30 01:23:05 +04:00
|
|
|
/* drm_mm doesn't allow any other other operations while
|
2016-08-04 18:32:17 +03:00
|
|
|
* scanning, therefore store to-be-evicted objects on a
|
|
|
|
* temporary list and take a reference for all before
|
|
|
|
* calling unbind (which may remove the active reference
|
|
|
|
* of any of our objects, thus corrupting the list).
|
|
|
|
*/
|
2017-06-15 11:14:35 +03:00
|
|
|
list_for_each_entry_safe(vma, next, &eviction_list, evict_link) {
|
2016-12-22 11:36:29 +03:00
|
|
|
if (drm_mm_scan_remove_block(&scan, &vma->node))
|
2016-08-04 18:32:30 +03:00
|
|
|
__i915_vma_pin(vma);
|
2016-08-04 18:32:17 +03:00
|
|
|
else
|
2017-06-15 11:14:35 +03:00
|
|
|
list_del(&vma->evict_link);
|
2010-08-07 14:01:24 +04:00
|
|
|
}
|
2010-08-07 14:01:23 +04:00
|
|
|
|
2010-08-07 14:01:24 +04:00
|
|
|
/* Unbinding will emit any required flushes */
|
2017-01-05 18:59:40 +03:00
|
|
|
ret = 0;
|
2017-06-15 11:14:35 +03:00
|
|
|
list_for_each_entry_safe(vma, next, &eviction_list, evict_link) {
|
2016-08-04 18:32:30 +03:00
|
|
|
__i915_vma_unpin(vma);
|
2010-09-30 01:23:05 +04:00
|
|
|
if (ret == 0)
|
drm/i915: Pull i915_vma_pin under the vm->mutex
Replace the struct_mutex requirement for pinning the i915_vma with the
local vm->mutex instead. Note that the vm->mutex is tainted by the
shrinker (we require unbinding from inside fs-reclaim) and so we cannot
allocate while holding that mutex. Instead we have to preallocate
workers to do allocate and apply the PTE updates after we have we
reserved their slot in the drm_mm (using fences to order the PTE writes
with the GPU work and with later unbind).
In adding the asynchronous vma binding, one subtle requirement is to
avoid coupling the binding fence into the backing object->resv. That is
the asynchronous binding only applies to the vma timeline itself and not
to the pages as that is a more global timeline (the binding of one vma
does not need to be ordered with another vma, nor does the implicit GEM
fencing depend on a vma, only on writes to the backing store). Keeping
the vma binding distinct from the backing store timelines is verified by
a number of async gem_exec_fence and gem_exec_schedule tests. The way we
do this is quite simple, we keep the fence for the vma binding separate
and only wait on it as required, and never add it to the obj->resv
itself.
Another consequence in reducing the locking around the vma is the
destruction of the vma is no longer globally serialised by struct_mutex.
A natural solution would be to add a kref to i915_vma, but that requires
decoupling the reference cycles, possibly by introducing a new
i915_mm_pages object that is own by both obj->mm and vma->pages.
However, we have not taken that route due to the overshadowing lmem/ttm
discussions, and instead play a series of complicated games with
trylocks to (hopefully) ensure that only one destruction path is called!
v2: Add some commentary, and some helpers to reduce patch churn.
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/20191004134015.13204-4-chris@chris-wilson.co.uk
2019-10-04 16:39:58 +03:00
|
|
|
ret = __i915_vma_unbind(vma);
|
2010-08-07 14:01:23 +04:00
|
|
|
}
|
2016-12-22 11:36:36 +03:00
|
|
|
|
|
|
|
while (ret == 0 && (node = drm_mm_scan_color_evict(&scan))) {
|
|
|
|
vma = container_of(node, struct i915_vma, node);
|
drm/i915: Pull i915_vma_pin under the vm->mutex
Replace the struct_mutex requirement for pinning the i915_vma with the
local vm->mutex instead. Note that the vm->mutex is tainted by the
shrinker (we require unbinding from inside fs-reclaim) and so we cannot
allocate while holding that mutex. Instead we have to preallocate
workers to do allocate and apply the PTE updates after we have we
reserved their slot in the drm_mm (using fences to order the PTE writes
with the GPU work and with later unbind).
In adding the asynchronous vma binding, one subtle requirement is to
avoid coupling the binding fence into the backing object->resv. That is
the asynchronous binding only applies to the vma timeline itself and not
to the pages as that is a more global timeline (the binding of one vma
does not need to be ordered with another vma, nor does the implicit GEM
fencing depend on a vma, only on writes to the backing store). Keeping
the vma binding distinct from the backing store timelines is verified by
a number of async gem_exec_fence and gem_exec_schedule tests. The way we
do this is quite simple, we keep the fence for the vma binding separate
and only wait on it as required, and never add it to the obj->resv
itself.
Another consequence in reducing the locking around the vma is the
destruction of the vma is no longer globally serialised by struct_mutex.
A natural solution would be to add a kref to i915_vma, but that requires
decoupling the reference cycles, possibly by introducing a new
i915_mm_pages object that is own by both obj->mm and vma->pages.
However, we have not taken that route due to the overshadowing lmem/ttm
discussions, and instead play a series of complicated games with
trylocks to (hopefully) ensure that only one destruction path is called!
v2: Add some commentary, and some helpers to reduce patch churn.
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/20191004134015.13204-4-chris@chris-wilson.co.uk
2019-10-04 16:39:58 +03:00
|
|
|
ret = __i915_vma_unbind(vma);
|
2016-12-22 11:36:36 +03:00
|
|
|
}
|
|
|
|
|
2010-09-30 01:23:05 +04:00
|
|
|
return ret;
|
2010-08-07 14:01:23 +04:00
|
|
|
}
|
|
|
|
|
2016-12-05 17:29:37 +03:00
|
|
|
/**
|
|
|
|
* i915_gem_evict_for_vma - Evict vmas to make room for binding a new one
|
2017-01-11 14:23:11 +03:00
|
|
|
* @vm: address space to evict from
|
|
|
|
* @target: range (and color) to evict for
|
2016-12-05 17:29:37 +03:00
|
|
|
* @flags: additional flags to control the eviction algorithm
|
|
|
|
*
|
|
|
|
* This function will try to evict vmas that overlap the target node.
|
|
|
|
*
|
|
|
|
* To clarify: This is for freeing up virtual address space, not for freeing
|
|
|
|
* memory in e.g. the shrinker.
|
|
|
|
*/
|
2017-01-11 14:23:11 +03:00
|
|
|
int i915_gem_evict_for_node(struct i915_address_space *vm,
|
|
|
|
struct drm_mm_node *target,
|
|
|
|
unsigned int flags)
|
2015-12-08 14:55:07 +03:00
|
|
|
{
|
2016-12-05 17:29:37 +03:00
|
|
|
LIST_HEAD(eviction_list);
|
|
|
|
struct drm_mm_node *node;
|
2017-01-11 14:23:11 +03:00
|
|
|
u64 start = target->start;
|
|
|
|
u64 end = start + target->size;
|
2016-12-05 17:29:37 +03:00
|
|
|
struct i915_vma *vma, *next;
|
|
|
|
int ret = 0;
|
2015-12-08 14:55:07 +03:00
|
|
|
|
drm/i915: Pull i915_vma_pin under the vm->mutex
Replace the struct_mutex requirement for pinning the i915_vma with the
local vm->mutex instead. Note that the vm->mutex is tainted by the
shrinker (we require unbinding from inside fs-reclaim) and so we cannot
allocate while holding that mutex. Instead we have to preallocate
workers to do allocate and apply the PTE updates after we have we
reserved their slot in the drm_mm (using fences to order the PTE writes
with the GPU work and with later unbind).
In adding the asynchronous vma binding, one subtle requirement is to
avoid coupling the binding fence into the backing object->resv. That is
the asynchronous binding only applies to the vma timeline itself and not
to the pages as that is a more global timeline (the binding of one vma
does not need to be ordered with another vma, nor does the implicit GEM
fencing depend on a vma, only on writes to the backing store). Keeping
the vma binding distinct from the backing store timelines is verified by
a number of async gem_exec_fence and gem_exec_schedule tests. The way we
do this is quite simple, we keep the fence for the vma binding separate
and only wait on it as required, and never add it to the obj->resv
itself.
Another consequence in reducing the locking around the vma is the
destruction of the vma is no longer globally serialised by struct_mutex.
A natural solution would be to add a kref to i915_vma, but that requires
decoupling the reference cycles, possibly by introducing a new
i915_mm_pages object that is own by both obj->mm and vma->pages.
However, we have not taken that route due to the overshadowing lmem/ttm
discussions, and instead play a series of complicated games with
trylocks to (hopefully) ensure that only one destruction path is called!
v2: Add some commentary, and some helpers to reduce patch churn.
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/20191004134015.13204-4-chris@chris-wilson.co.uk
2019-10-04 16:39:58 +03:00
|
|
|
lockdep_assert_held(&vm->mutex);
|
2017-02-06 11:45:47 +03:00
|
|
|
GEM_BUG_ON(!IS_ALIGNED(start, I915_GTT_PAGE_SIZE));
|
|
|
|
GEM_BUG_ON(!IS_ALIGNED(end, I915_GTT_PAGE_SIZE));
|
|
|
|
|
2017-01-11 14:23:11 +03:00
|
|
|
trace_i915_gem_evict_node(vm, target, flags);
|
2016-12-05 17:29:37 +03:00
|
|
|
|
2019-10-04 16:40:04 +03:00
|
|
|
/*
|
|
|
|
* Retire before we search the active list. Although we have
|
2016-12-09 18:05:55 +03:00
|
|
|
* reasonable accuracy in our retirement lists, we may have
|
|
|
|
* a stray pin (preventing eviction) that can only be resolved by
|
|
|
|
* retiring.
|
|
|
|
*/
|
2019-10-04 16:40:06 +03:00
|
|
|
intel_gt_retire_requests(vm->gt);
|
2016-12-09 18:05:55 +03:00
|
|
|
|
2019-09-09 15:40:52 +03:00
|
|
|
if (i915_vm_has_cache_coloring(vm)) {
|
2016-12-05 17:29:37 +03:00
|
|
|
/* Expand search to cover neighbouring guard pages (or lack!) */
|
2017-02-15 11:43:54 +03:00
|
|
|
if (start)
|
2017-01-10 17:47:34 +03:00
|
|
|
start -= I915_GTT_PAGE_SIZE;
|
2017-02-06 11:45:47 +03:00
|
|
|
|
|
|
|
/* Always look at the page afterwards to avoid the end-of-GTT */
|
|
|
|
end += I915_GTT_PAGE_SIZE;
|
2016-12-05 17:29:37 +03:00
|
|
|
}
|
2017-02-06 11:45:47 +03:00
|
|
|
GEM_BUG_ON(start >= end);
|
2016-10-28 15:58:32 +03:00
|
|
|
|
2017-01-11 14:23:11 +03:00
|
|
|
drm_mm_for_each_node_in_range(node, &vm->mm, start, end) {
|
2016-12-05 17:29:37 +03:00
|
|
|
/* If we find any non-objects (!vma), we cannot evict them */
|
|
|
|
if (node->color == I915_COLOR_UNEVICTABLE) {
|
|
|
|
ret = -ENOSPC;
|
2015-12-08 14:55:07 +03:00
|
|
|
break;
|
2016-12-05 17:29:37 +03:00
|
|
|
}
|
2015-12-08 14:55:07 +03:00
|
|
|
|
2019-10-04 00:00:58 +03:00
|
|
|
GEM_BUG_ON(!drm_mm_node_allocated(node));
|
2015-12-08 14:55:07 +03:00
|
|
|
vma = container_of(node, typeof(*vma), node);
|
|
|
|
|
2016-12-05 17:29:37 +03:00
|
|
|
/* If we are using coloring to insert guard pages between
|
|
|
|
* different cache domains within the address space, we have
|
|
|
|
* to check whether the objects on either side of our range
|
|
|
|
* abutt and conflict. If they are in conflict, then we evict
|
|
|
|
* those as well to make room for our guard pages.
|
|
|
|
*/
|
2019-09-09 15:40:52 +03:00
|
|
|
if (i915_vm_has_cache_coloring(vm)) {
|
2017-03-07 02:54:01 +03:00
|
|
|
if (node->start + node->size == target->start) {
|
|
|
|
if (node->color == target->color)
|
2016-12-05 17:29:37 +03:00
|
|
|
continue;
|
|
|
|
}
|
2017-03-07 02:54:01 +03:00
|
|
|
if (node->start == target->start + target->size) {
|
|
|
|
if (node->color == target->color)
|
2016-12-05 17:29:37 +03:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
2015-12-08 14:55:07 +03:00
|
|
|
|
2016-12-05 17:29:37 +03:00
|
|
|
if (flags & PIN_NONBLOCK &&
|
|
|
|
(i915_vma_is_pinned(vma) || i915_vma_is_active(vma))) {
|
|
|
|
ret = -ENOSPC;
|
|
|
|
break;
|
|
|
|
}
|
2015-12-08 14:55:07 +03:00
|
|
|
|
2016-12-05 17:29:37 +03:00
|
|
|
/* Overlap of objects in the same batch? */
|
2017-06-15 11:14:34 +03:00
|
|
|
if (i915_vma_is_pinned(vma)) {
|
2016-12-05 17:29:37 +03:00
|
|
|
ret = -ENOSPC;
|
2017-08-16 11:52:06 +03:00
|
|
|
if (vma->exec_flags &&
|
|
|
|
*vma->exec_flags & EXEC_OBJECT_PINNED)
|
2016-12-05 17:29:37 +03:00
|
|
|
ret = -EINVAL;
|
|
|
|
break;
|
2015-12-08 14:55:07 +03:00
|
|
|
}
|
|
|
|
|
2016-12-05 17:29:37 +03:00
|
|
|
/* Never show fear in the face of dragons!
|
|
|
|
*
|
|
|
|
* We cannot directly remove this node from within this
|
|
|
|
* iterator and as with i915_gem_evict_something() we employ
|
|
|
|
* the vma pin_count in order to prevent the action of
|
|
|
|
* unbinding one vma from freeing (by dropping its active
|
|
|
|
* reference) another in our eviction list.
|
|
|
|
*/
|
|
|
|
__i915_vma_pin(vma);
|
2017-06-15 11:14:35 +03:00
|
|
|
list_add(&vma->evict_link, &eviction_list);
|
2016-12-05 17:29:37 +03:00
|
|
|
}
|
|
|
|
|
2017-06-15 11:14:35 +03:00
|
|
|
list_for_each_entry_safe(vma, next, &eviction_list, evict_link) {
|
2016-12-05 17:29:37 +03:00
|
|
|
__i915_vma_unpin(vma);
|
|
|
|
if (ret == 0)
|
drm/i915: Pull i915_vma_pin under the vm->mutex
Replace the struct_mutex requirement for pinning the i915_vma with the
local vm->mutex instead. Note that the vm->mutex is tainted by the
shrinker (we require unbinding from inside fs-reclaim) and so we cannot
allocate while holding that mutex. Instead we have to preallocate
workers to do allocate and apply the PTE updates after we have we
reserved their slot in the drm_mm (using fences to order the PTE writes
with the GPU work and with later unbind).
In adding the asynchronous vma binding, one subtle requirement is to
avoid coupling the binding fence into the backing object->resv. That is
the asynchronous binding only applies to the vma timeline itself and not
to the pages as that is a more global timeline (the binding of one vma
does not need to be ordered with another vma, nor does the implicit GEM
fencing depend on a vma, only on writes to the backing store). Keeping
the vma binding distinct from the backing store timelines is verified by
a number of async gem_exec_fence and gem_exec_schedule tests. The way we
do this is quite simple, we keep the fence for the vma binding separate
and only wait on it as required, and never add it to the obj->resv
itself.
Another consequence in reducing the locking around the vma is the
destruction of the vma is no longer globally serialised by struct_mutex.
A natural solution would be to add a kref to i915_vma, but that requires
decoupling the reference cycles, possibly by introducing a new
i915_mm_pages object that is own by both obj->mm and vma->pages.
However, we have not taken that route due to the overshadowing lmem/ttm
discussions, and instead play a series of complicated games with
trylocks to (hopefully) ensure that only one destruction path is called!
v2: Add some commentary, and some helpers to reduce patch churn.
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/20191004134015.13204-4-chris@chris-wilson.co.uk
2019-10-04 16:39:58 +03:00
|
|
|
ret = __i915_vma_unbind(vma);
|
2015-12-08 14:55:07 +03:00
|
|
|
}
|
|
|
|
|
2016-12-05 17:29:37 +03:00
|
|
|
return ret;
|
2015-12-08 14:55:07 +03:00
|
|
|
}
|
|
|
|
|
2013-09-12 01:57:50 +04:00
|
|
|
/**
|
2014-01-30 01:07:11 +04:00
|
|
|
* i915_gem_evict_vm - Evict all idle vmas from a vm
|
|
|
|
* @vm: Address space to cleanse
|
2013-09-12 01:57:50 +04:00
|
|
|
*
|
drm/i915: Eliminate lots of iterations over the execobjects array
The major scaling bottleneck in execbuffer is the processing of the
execobjects. Creating an auxiliary list is inefficient when compared to
using the execobject array we already have allocated.
Reservation is then split into phases. As we lookup up the VMA, we
try and bind it back into active location. Only if that fails, do we add
it to the unbound list for phase 2. In phase 2, we try and add all those
objects that could not fit into their previous location, with fallback
to retrying all objects and evicting the VM in case of severe
fragmentation. (This is the same as before, except that phase 1 is now
done inline with looking up the VMA to avoid an iteration over the
execobject array. In the ideal case, we eliminate the separate reservation
phase). During the reservation phase, we only evict from the VM between
passes (rather than currently as we try to fit every new VMA). In
testing with Unreal Engine's Atlantis demo which stresses the eviction
logic on gen7 class hardware, this speed up the framerate by a factor of
2.
The second loop amalgamation is between move_to_gpu and move_to_active.
As we always submit the request, even if incomplete, we can use the
current request to track active VMA as we perform the flushes and
synchronisation required.
The next big advancement is to avoid copying back to the user any
execobjects and relocations that are not changed.
v2: Add a Theory of Operation spiel.
v3: Fall back to slow relocations in preparation for flushing userptrs.
v4: Document struct members, factor out eb_validate_vma(), add a few
more comments to explain some magic and hide other magic behind macros.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2017-06-16 17:05:19 +03:00
|
|
|
* This function evicts all vmas from a vm.
|
2013-09-12 01:57:50 +04:00
|
|
|
*
|
2014-01-30 01:07:11 +04:00
|
|
|
* This is used by the execbuf code as a last-ditch effort to defragment the
|
|
|
|
* address space.
|
|
|
|
*
|
|
|
|
* To clarify: This is for freeing up virtual address space, not for freeing
|
|
|
|
* memory in e.g. the shrinker.
|
2013-09-12 01:57:50 +04:00
|
|
|
*/
|
drm/i915: Eliminate lots of iterations over the execobjects array
The major scaling bottleneck in execbuffer is the processing of the
execobjects. Creating an auxiliary list is inefficient when compared to
using the execobject array we already have allocated.
Reservation is then split into phases. As we lookup up the VMA, we
try and bind it back into active location. Only if that fails, do we add
it to the unbound list for phase 2. In phase 2, we try and add all those
objects that could not fit into their previous location, with fallback
to retrying all objects and evicting the VM in case of severe
fragmentation. (This is the same as before, except that phase 1 is now
done inline with looking up the VMA to avoid an iteration over the
execobject array. In the ideal case, we eliminate the separate reservation
phase). During the reservation phase, we only evict from the VM between
passes (rather than currently as we try to fit every new VMA). In
testing with Unreal Engine's Atlantis demo which stresses the eviction
logic on gen7 class hardware, this speed up the framerate by a factor of
2.
The second loop amalgamation is between move_to_gpu and move_to_active.
As we always submit the request, even if incomplete, we can use the
current request to track active VMA as we perform the flushes and
synchronisation required.
The next big advancement is to avoid copying back to the user any
execobjects and relocations that are not changed.
v2: Add a Theory of Operation spiel.
v3: Fall back to slow relocations in preparation for flushing userptrs.
v4: Document struct members, factor out eb_validate_vma(), add a few
more comments to explain some magic and hide other magic behind macros.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2017-06-16 17:05:19 +03:00
|
|
|
int i915_gem_evict_vm(struct i915_address_space *vm)
|
2013-09-12 01:57:49 +04:00
|
|
|
{
|
drm/i915: Eliminate lots of iterations over the execobjects array
The major scaling bottleneck in execbuffer is the processing of the
execobjects. Creating an auxiliary list is inefficient when compared to
using the execobject array we already have allocated.
Reservation is then split into phases. As we lookup up the VMA, we
try and bind it back into active location. Only if that fails, do we add
it to the unbound list for phase 2. In phase 2, we try and add all those
objects that could not fit into their previous location, with fallback
to retrying all objects and evicting the VM in case of severe
fragmentation. (This is the same as before, except that phase 1 is now
done inline with looking up the VMA to avoid an iteration over the
execobject array. In the ideal case, we eliminate the separate reservation
phase). During the reservation phase, we only evict from the VM between
passes (rather than currently as we try to fit every new VMA). In
testing with Unreal Engine's Atlantis demo which stresses the eviction
logic on gen7 class hardware, this speed up the framerate by a factor of
2.
The second loop amalgamation is between move_to_gpu and move_to_active.
As we always submit the request, even if incomplete, we can use the
current request to track active VMA as we perform the flushes and
synchronisation required.
The next big advancement is to avoid copying back to the user any
execobjects and relocations that are not changed.
v2: Add a Theory of Operation spiel.
v3: Fall back to slow relocations in preparation for flushing userptrs.
v4: Document struct members, factor out eb_validate_vma(), add a few
more comments to explain some magic and hide other magic behind macros.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2017-06-16 17:05:19 +03:00
|
|
|
struct list_head eviction_list;
|
2013-09-12 01:57:49 +04:00
|
|
|
struct i915_vma *vma, *next;
|
|
|
|
int ret;
|
|
|
|
|
drm/i915: Pull i915_vma_pin under the vm->mutex
Replace the struct_mutex requirement for pinning the i915_vma with the
local vm->mutex instead. Note that the vm->mutex is tainted by the
shrinker (we require unbinding from inside fs-reclaim) and so we cannot
allocate while holding that mutex. Instead we have to preallocate
workers to do allocate and apply the PTE updates after we have we
reserved their slot in the drm_mm (using fences to order the PTE writes
with the GPU work and with later unbind).
In adding the asynchronous vma binding, one subtle requirement is to
avoid coupling the binding fence into the backing object->resv. That is
the asynchronous binding only applies to the vma timeline itself and not
to the pages as that is a more global timeline (the binding of one vma
does not need to be ordered with another vma, nor does the implicit GEM
fencing depend on a vma, only on writes to the backing store). Keeping
the vma binding distinct from the backing store timelines is verified by
a number of async gem_exec_fence and gem_exec_schedule tests. The way we
do this is quite simple, we keep the fence for the vma binding separate
and only wait on it as required, and never add it to the obj->resv
itself.
Another consequence in reducing the locking around the vma is the
destruction of the vma is no longer globally serialised by struct_mutex.
A natural solution would be to add a kref to i915_vma, but that requires
decoupling the reference cycles, possibly by introducing a new
i915_mm_pages object that is own by both obj->mm and vma->pages.
However, we have not taken that route due to the overshadowing lmem/ttm
discussions, and instead play a series of complicated games with
trylocks to (hopefully) ensure that only one destruction path is called!
v2: Add some commentary, and some helpers to reduce patch churn.
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/20191004134015.13204-4-chris@chris-wilson.co.uk
2019-10-04 16:39:58 +03:00
|
|
|
lockdep_assert_held(&vm->mutex);
|
2013-09-24 20:57:56 +04:00
|
|
|
trace_i915_gem_evict_vm(vm);
|
|
|
|
|
drm/i915: Eliminate lots of iterations over the execobjects array
The major scaling bottleneck in execbuffer is the processing of the
execobjects. Creating an auxiliary list is inefficient when compared to
using the execobject array we already have allocated.
Reservation is then split into phases. As we lookup up the VMA, we
try and bind it back into active location. Only if that fails, do we add
it to the unbound list for phase 2. In phase 2, we try and add all those
objects that could not fit into their previous location, with fallback
to retrying all objects and evicting the VM in case of severe
fragmentation. (This is the same as before, except that phase 1 is now
done inline with looking up the VMA to avoid an iteration over the
execobject array. In the ideal case, we eliminate the separate reservation
phase). During the reservation phase, we only evict from the VM between
passes (rather than currently as we try to fit every new VMA). In
testing with Unreal Engine's Atlantis demo which stresses the eviction
logic on gen7 class hardware, this speed up the framerate by a factor of
2.
The second loop amalgamation is between move_to_gpu and move_to_active.
As we always submit the request, even if incomplete, we can use the
current request to track active VMA as we perform the flushes and
synchronisation required.
The next big advancement is to avoid copying back to the user any
execobjects and relocations that are not changed.
v2: Add a Theory of Operation spiel.
v3: Fall back to slow relocations in preparation for flushing userptrs.
v4: Document struct members, factor out eb_validate_vma(), add a few
more comments to explain some magic and hide other magic behind macros.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2017-06-16 17:05:19 +03:00
|
|
|
/* Switch back to the default context in order to unpin
|
|
|
|
* the existing context objects. However, such objects only
|
|
|
|
* pin themselves inside the global GTT and performing the
|
|
|
|
* switch otherwise is ineffective.
|
|
|
|
*/
|
|
|
|
if (i915_is_ggtt(vm)) {
|
2019-10-04 16:40:06 +03:00
|
|
|
ret = ggtt_flush(vm->gt);
|
2013-09-12 01:57:49 +04:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
drm/i915: Eliminate lots of iterations over the execobjects array
The major scaling bottleneck in execbuffer is the processing of the
execobjects. Creating an auxiliary list is inefficient when compared to
using the execobject array we already have allocated.
Reservation is then split into phases. As we lookup up the VMA, we
try and bind it back into active location. Only if that fails, do we add
it to the unbound list for phase 2. In phase 2, we try and add all those
objects that could not fit into their previous location, with fallback
to retrying all objects and evicting the VM in case of severe
fragmentation. (This is the same as before, except that phase 1 is now
done inline with looking up the VMA to avoid an iteration over the
execobject array. In the ideal case, we eliminate the separate reservation
phase). During the reservation phase, we only evict from the VM between
passes (rather than currently as we try to fit every new VMA). In
testing with Unreal Engine's Atlantis demo which stresses the eviction
logic on gen7 class hardware, this speed up the framerate by a factor of
2.
The second loop amalgamation is between move_to_gpu and move_to_active.
As we always submit the request, even if incomplete, we can use the
current request to track active VMA as we perform the flushes and
synchronisation required.
The next big advancement is to avoid copying back to the user any
execobjects and relocations that are not changed.
v2: Add a Theory of Operation spiel.
v3: Fall back to slow relocations in preparation for flushing userptrs.
v4: Document struct members, factor out eb_validate_vma(), add a few
more comments to explain some magic and hide other magic behind macros.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2017-06-16 17:05:19 +03:00
|
|
|
INIT_LIST_HEAD(&eviction_list);
|
2019-01-28 13:23:52 +03:00
|
|
|
list_for_each_entry(vma, &vm->bound_list, vm_link) {
|
|
|
|
if (i915_vma_is_pinned(vma))
|
|
|
|
continue;
|
2013-09-12 01:57:49 +04:00
|
|
|
|
2019-01-28 13:23:52 +03:00
|
|
|
__i915_vma_pin(vma);
|
|
|
|
list_add(&vma->evict_link, &eviction_list);
|
|
|
|
}
|
drm/i915: Eliminate lots of iterations over the execobjects array
The major scaling bottleneck in execbuffer is the processing of the
execobjects. Creating an auxiliary list is inefficient when compared to
using the execobject array we already have allocated.
Reservation is then split into phases. As we lookup up the VMA, we
try and bind it back into active location. Only if that fails, do we add
it to the unbound list for phase 2. In phase 2, we try and add all those
objects that could not fit into their previous location, with fallback
to retrying all objects and evicting the VM in case of severe
fragmentation. (This is the same as before, except that phase 1 is now
done inline with looking up the VMA to avoid an iteration over the
execobject array. In the ideal case, we eliminate the separate reservation
phase). During the reservation phase, we only evict from the VM between
passes (rather than currently as we try to fit every new VMA). In
testing with Unreal Engine's Atlantis demo which stresses the eviction
logic on gen7 class hardware, this speed up the framerate by a factor of
2.
The second loop amalgamation is between move_to_gpu and move_to_active.
As we always submit the request, even if incomplete, we can use the
current request to track active VMA as we perform the flushes and
synchronisation required.
The next big advancement is to avoid copying back to the user any
execobjects and relocations that are not changed.
v2: Add a Theory of Operation spiel.
v3: Fall back to slow relocations in preparation for flushing userptrs.
v4: Document struct members, factor out eb_validate_vma(), add a few
more comments to explain some magic and hide other magic behind macros.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2017-06-16 17:05:19 +03:00
|
|
|
|
|
|
|
ret = 0;
|
|
|
|
list_for_each_entry_safe(vma, next, &eviction_list, evict_link) {
|
|
|
|
__i915_vma_unpin(vma);
|
|
|
|
if (ret == 0)
|
drm/i915: Pull i915_vma_pin under the vm->mutex
Replace the struct_mutex requirement for pinning the i915_vma with the
local vm->mutex instead. Note that the vm->mutex is tainted by the
shrinker (we require unbinding from inside fs-reclaim) and so we cannot
allocate while holding that mutex. Instead we have to preallocate
workers to do allocate and apply the PTE updates after we have we
reserved their slot in the drm_mm (using fences to order the PTE writes
with the GPU work and with later unbind).
In adding the asynchronous vma binding, one subtle requirement is to
avoid coupling the binding fence into the backing object->resv. That is
the asynchronous binding only applies to the vma timeline itself and not
to the pages as that is a more global timeline (the binding of one vma
does not need to be ordered with another vma, nor does the implicit GEM
fencing depend on a vma, only on writes to the backing store). Keeping
the vma binding distinct from the backing store timelines is verified by
a number of async gem_exec_fence and gem_exec_schedule tests. The way we
do this is quite simple, we keep the fence for the vma binding separate
and only wait on it as required, and never add it to the obj->resv
itself.
Another consequence in reducing the locking around the vma is the
destruction of the vma is no longer globally serialised by struct_mutex.
A natural solution would be to add a kref to i915_vma, but that requires
decoupling the reference cycles, possibly by introducing a new
i915_mm_pages object that is own by both obj->mm and vma->pages.
However, we have not taken that route due to the overshadowing lmem/ttm
discussions, and instead play a series of complicated games with
trylocks to (hopefully) ensure that only one destruction path is called!
v2: Add some commentary, and some helpers to reduce patch churn.
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/20191004134015.13204-4-chris@chris-wilson.co.uk
2019-10-04 16:39:58 +03:00
|
|
|
ret = __i915_vma_unbind(vma);
|
drm/i915: Eliminate lots of iterations over the execobjects array
The major scaling bottleneck in execbuffer is the processing of the
execobjects. Creating an auxiliary list is inefficient when compared to
using the execobject array we already have allocated.
Reservation is then split into phases. As we lookup up the VMA, we
try and bind it back into active location. Only if that fails, do we add
it to the unbound list for phase 2. In phase 2, we try and add all those
objects that could not fit into their previous location, with fallback
to retrying all objects and evicting the VM in case of severe
fragmentation. (This is the same as before, except that phase 1 is now
done inline with looking up the VMA to avoid an iteration over the
execobject array. In the ideal case, we eliminate the separate reservation
phase). During the reservation phase, we only evict from the VM between
passes (rather than currently as we try to fit every new VMA). In
testing with Unreal Engine's Atlantis demo which stresses the eviction
logic on gen7 class hardware, this speed up the framerate by a factor of
2.
The second loop amalgamation is between move_to_gpu and move_to_active.
As we always submit the request, even if incomplete, we can use the
current request to track active VMA as we perform the flushes and
synchronisation required.
The next big advancement is to avoid copying back to the user any
execobjects and relocations that are not changed.
v2: Add a Theory of Operation spiel.
v3: Fall back to slow relocations in preparation for flushing userptrs.
v4: Document struct members, factor out eb_validate_vma(), add a few
more comments to explain some magic and hide other magic behind macros.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2017-06-16 17:05:19 +03:00
|
|
|
}
|
|
|
|
return ret;
|
2013-09-12 01:57:49 +04:00
|
|
|
}
|
2017-02-13 20:15:52 +03:00
|
|
|
|
|
|
|
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
|
|
|
|
#include "selftests/i915_gem_evict.c"
|
|
|
|
#endif
|