2010-08-07 10:01:23 +00: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 17:01:07 +00:00
|
|
|
#include <drm/drmP.h>
|
|
|
|
#include <drm/i915_drm.h>
|
2014-01-20 10:17:37 +00:00
|
|
|
|
|
|
|
#include "i915_drv.h"
|
|
|
|
#include "intel_drv.h"
|
2011-02-03 11:57:46 +00:00
|
|
|
#include "i915_trace.h"
|
2010-08-07 10:01:23 +00:00
|
|
|
|
2010-08-07 10:01:24 +00:00
|
|
|
static bool
|
2013-08-01 00:00:11 +00:00
|
|
|
mark_free(struct i915_vma *vma, struct list_head *unwind)
|
2010-08-07 10:01:23 +00:00
|
|
|
{
|
2014-01-28 18:08:38 +00:00
|
|
|
if (vma->pin_count)
|
2012-04-24 14:47:30 +00:00
|
|
|
return false;
|
|
|
|
|
2013-08-26 09:23:47 +00:00
|
|
|
if (WARN_ON(!list_empty(&vma->exec_list)))
|
|
|
|
return false;
|
|
|
|
|
2013-08-14 09:38:34 +00:00
|
|
|
list_add(&vma->exec_list, unwind);
|
2013-07-17 19:19:03 +00:00
|
|
|
return drm_mm_scan_add_block(&vma->node);
|
2010-08-07 10:01:23 +00:00
|
|
|
}
|
|
|
|
|
2014-01-29 21:07:11 +00:00
|
|
|
/**
|
|
|
|
* i915_gem_evict_something - Evict vmas to make room for binding a new one
|
|
|
|
* @dev: drm_device
|
|
|
|
* @vm: address space to evict from
|
|
|
|
* @size: size of the desired free space
|
|
|
|
* @alignment: alignment constraint of the desired free space
|
|
|
|
* @cache_level: cache_level for the desired space
|
|
|
|
* @mappable: whether the free space must be mappable
|
|
|
|
* @nonblocking: whether evicting active objects is allowed or not
|
|
|
|
*
|
|
|
|
* 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.
|
|
|
|
*
|
|
|
|
* To clarify: This is for freeing up virtual address space, not for freeing
|
|
|
|
* memory in e.g. the shrinker.
|
|
|
|
*/
|
2010-08-07 10:01:23 +00:00
|
|
|
int
|
2013-08-01 00:00:11 +00:00
|
|
|
i915_gem_evict_something(struct drm_device *dev, struct i915_address_space *vm,
|
|
|
|
int min_size, unsigned alignment, unsigned cache_level,
|
drm/i915: Prevent negative relocation deltas from wrapping
This is pure evil. Userspace, I'm looking at you SNA, repacks batch
buffers on the fly after generation as they are being passed to the
kernel for execution. These batches also contain self-referenced
relocations as a single buffer encompasses the state commands, kernels,
vertices and sampler. During generation the buffers are placed at known
offsets within the full batch, and then the relocation deltas (as passed
to the kernel) are tweaked as the batch is repacked into a smaller buffer.
This means that userspace is passing negative relocations deltas, which
subsequently wrap to large values if the batch is at a low address. The
GPU hangs when it then tries to use the large value as a base for its
address offsets, rather than wrapping back to the real value (as one
would hope). As the GPU uses positive offsets from the base, we can
treat the relocation address as the minimum address read by the GPU.
For the upper bound, we trust that userspace will not read beyond the
end of the buffer.
So, how do we fix negative relocations from wrapping? We can either
check that every relocation looks valid when we write it, and then
position each object such that we prevent the offset wraparound, or we
just special-case the self-referential behaviour of SNA and force all
batches to be above 256k. Daniel prefers the latter approach.
This fixes a GPU hang when it tries to use an address (relocation +
offset) greater than the GTT size. The issue would occur quite easily
with full-ppgtt as each fd gets its own VM space, so low offsets would
often be handed out. However, with the rearrangement of the low GTT due
to capturing the BIOS framebuffer, it is already affecting kernels 3.15
onwards. I think only IVB+ is susceptible to this bug, but the workaround
should only kick in rarely, so it seems sensible to always apply it.
v3: Use a bias for batch buffers to prevent small negative delta relocations
from wrapping.
v4 from Daniel:
- s/BIAS/BATCH_OFFSET_BIAS/
- Extract eb_vma_misplaced/i915_vma_misplaced since the conditions
were growing rather cumbersome.
- Add a comment to eb_get_batch explaining why we do this.
- Apply the batch offset bias everywhere but mention that we've only
observed it on gen7 gpus.
- Drop PIN_OFFSET_FIX for now, that slipped in from a feature patch.
v5: Add static to eb_get_batch, spotted by 0-day tester.
Testcase: igt/gem_bad_reloc
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78533
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v3)
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-23 06:48:08 +00:00
|
|
|
unsigned long start, unsigned long end,
|
2014-02-14 13:01:11 +00:00
|
|
|
unsigned flags)
|
2010-08-07 10:01:23 +00:00
|
|
|
{
|
2010-08-07 10:01:24 +00:00
|
|
|
struct list_head eviction_list, unwind_list;
|
2013-07-17 19:19:03 +00:00
|
|
|
struct i915_vma *vma;
|
2010-08-07 10:01:24 +00:00
|
|
|
int ret = 0;
|
2014-01-20 10:17:37 +00:00
|
|
|
int pass = 0;
|
2010-08-07 10:01:23 +00:00
|
|
|
|
2014-02-14 13:01:11 +00:00
|
|
|
trace_i915_gem_evict(dev, min_size, alignment, flags);
|
2011-02-03 11:57:46 +00:00
|
|
|
|
2010-08-07 10:01:24 +00:00
|
|
|
/*
|
|
|
|
* The goal is to evict objects and amalgamate space in LRU order.
|
|
|
|
* The oldest idle objects reside on the inactive list, which is in
|
|
|
|
* retirement order. The next objects to retire are those on the (per
|
|
|
|
* ring) active list that do not have an outstanding flush. Once the
|
|
|
|
* hardware reports completion (the seqno is updated after the
|
|
|
|
* batchbuffer has been finished) the clean buffer objects would
|
|
|
|
* be retired to the inactive list. Any dirty objects would be added
|
|
|
|
* to the tail of the flushing list. So after processing the clean
|
|
|
|
* active objects we need to emit a MI_FLUSH to retire the flushing
|
|
|
|
* list, hence the retirement order of the flushing list is in
|
|
|
|
* advance of the dirty objects on the active lists.
|
|
|
|
*
|
|
|
|
* The retirement sequence is thus:
|
|
|
|
* 1. Inactive objects (already retired)
|
|
|
|
* 2. Clean active objects
|
|
|
|
* 3. Flushing list
|
|
|
|
* 4. Dirty active objects.
|
|
|
|
*
|
|
|
|
* On each list, the oldest objects lie at the HEAD with the freshest
|
|
|
|
* object on the TAIL.
|
|
|
|
*/
|
|
|
|
|
|
|
|
INIT_LIST_HEAD(&unwind_list);
|
drm/i915: Prevent negative relocation deltas from wrapping
This is pure evil. Userspace, I'm looking at you SNA, repacks batch
buffers on the fly after generation as they are being passed to the
kernel for execution. These batches also contain self-referenced
relocations as a single buffer encompasses the state commands, kernels,
vertices and sampler. During generation the buffers are placed at known
offsets within the full batch, and then the relocation deltas (as passed
to the kernel) are tweaked as the batch is repacked into a smaller buffer.
This means that userspace is passing negative relocations deltas, which
subsequently wrap to large values if the batch is at a low address. The
GPU hangs when it then tries to use the large value as a base for its
address offsets, rather than wrapping back to the real value (as one
would hope). As the GPU uses positive offsets from the base, we can
treat the relocation address as the minimum address read by the GPU.
For the upper bound, we trust that userspace will not read beyond the
end of the buffer.
So, how do we fix negative relocations from wrapping? We can either
check that every relocation looks valid when we write it, and then
position each object such that we prevent the offset wraparound, or we
just special-case the self-referential behaviour of SNA and force all
batches to be above 256k. Daniel prefers the latter approach.
This fixes a GPU hang when it tries to use an address (relocation +
offset) greater than the GTT size. The issue would occur quite easily
with full-ppgtt as each fd gets its own VM space, so low offsets would
often be handed out. However, with the rearrangement of the low GTT due
to capturing the BIOS framebuffer, it is already affecting kernels 3.15
onwards. I think only IVB+ is susceptible to this bug, but the workaround
should only kick in rarely, so it seems sensible to always apply it.
v3: Use a bias for batch buffers to prevent small negative delta relocations
from wrapping.
v4 from Daniel:
- s/BIAS/BATCH_OFFSET_BIAS/
- Extract eb_vma_misplaced/i915_vma_misplaced since the conditions
were growing rather cumbersome.
- Add a comment to eb_get_batch explaining why we do this.
- Apply the batch offset bias everywhere but mention that we've only
observed it on gen7 gpus.
- Drop PIN_OFFSET_FIX for now, that slipped in from a feature patch.
v5: Add static to eb_get_batch, spotted by 0-day tester.
Testcase: igt/gem_bad_reloc
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78533
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v3)
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-23 06:48:08 +00:00
|
|
|
if (start != 0 || end != vm->total) {
|
2013-07-16 23:50:08 +00:00
|
|
|
drm_mm_init_scan_with_range(&vm->mm, min_size,
|
drm/i915: Prevent negative relocation deltas from wrapping
This is pure evil. Userspace, I'm looking at you SNA, repacks batch
buffers on the fly after generation as they are being passed to the
kernel for execution. These batches also contain self-referenced
relocations as a single buffer encompasses the state commands, kernels,
vertices and sampler. During generation the buffers are placed at known
offsets within the full batch, and then the relocation deltas (as passed
to the kernel) are tweaked as the batch is repacked into a smaller buffer.
This means that userspace is passing negative relocations deltas, which
subsequently wrap to large values if the batch is at a low address. The
GPU hangs when it then tries to use the large value as a base for its
address offsets, rather than wrapping back to the real value (as one
would hope). As the GPU uses positive offsets from the base, we can
treat the relocation address as the minimum address read by the GPU.
For the upper bound, we trust that userspace will not read beyond the
end of the buffer.
So, how do we fix negative relocations from wrapping? We can either
check that every relocation looks valid when we write it, and then
position each object such that we prevent the offset wraparound, or we
just special-case the self-referential behaviour of SNA and force all
batches to be above 256k. Daniel prefers the latter approach.
This fixes a GPU hang when it tries to use an address (relocation +
offset) greater than the GTT size. The issue would occur quite easily
with full-ppgtt as each fd gets its own VM space, so low offsets would
often be handed out. However, with the rearrangement of the low GTT due
to capturing the BIOS framebuffer, it is already affecting kernels 3.15
onwards. I think only IVB+ is susceptible to this bug, but the workaround
should only kick in rarely, so it seems sensible to always apply it.
v3: Use a bias for batch buffers to prevent small negative delta relocations
from wrapping.
v4 from Daniel:
- s/BIAS/BATCH_OFFSET_BIAS/
- Extract eb_vma_misplaced/i915_vma_misplaced since the conditions
were growing rather cumbersome.
- Add a comment to eb_get_batch explaining why we do this.
- Apply the batch offset bias everywhere but mention that we've only
observed it on gen7 gpus.
- Drop PIN_OFFSET_FIX for now, that slipped in from a feature patch.
v5: Add static to eb_get_batch, spotted by 0-day tester.
Testcase: igt/gem_bad_reloc
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78533
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v3)
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-23 06:48:08 +00:00
|
|
|
alignment, cache_level,
|
|
|
|
start, end);
|
2013-08-01 00:00:11 +00:00
|
|
|
} else
|
2013-07-16 23:50:08 +00:00
|
|
|
drm_mm_init_scan(&vm->mm, min_size, alignment, cache_level);
|
2010-08-07 10:01:24 +00:00
|
|
|
|
2013-12-09 10:37:24 +00:00
|
|
|
search_again:
|
2010-08-07 10:01:24 +00:00
|
|
|
/* First see if there is a large enough contiguous idle region... */
|
2013-08-01 00:00:14 +00:00
|
|
|
list_for_each_entry(vma, &vm->inactive_list, mm_list) {
|
2013-08-01 00:00:11 +00:00
|
|
|
if (mark_free(vma, &unwind_list))
|
2010-08-07 10:01:24 +00:00
|
|
|
goto found;
|
|
|
|
}
|
2010-08-07 10:01:23 +00:00
|
|
|
|
2014-02-14 13:01:11 +00:00
|
|
|
if (flags & PIN_NONBLOCK)
|
2012-08-11 14:41:04 +00:00
|
|
|
goto none;
|
2010-08-07 10:01:23 +00:00
|
|
|
|
2010-08-07 10:01:24 +00:00
|
|
|
/* Now merge in the soon-to-be-expired objects... */
|
2013-08-01 00:00:14 +00:00
|
|
|
list_for_each_entry(vma, &vm->active_list, mm_list) {
|
2013-08-01 00:00:11 +00:00
|
|
|
if (mark_free(vma, &unwind_list))
|
2010-08-07 10:01:24 +00:00
|
|
|
goto found;
|
|
|
|
}
|
|
|
|
|
2012-08-11 14:41:04 +00:00
|
|
|
none:
|
2010-08-07 10:01:24 +00:00
|
|
|
/* Nothing found, clean up and bail out! */
|
2011-01-10 14:21:05 +00:00
|
|
|
while (!list_empty(&unwind_list)) {
|
2013-08-14 09:38:34 +00:00
|
|
|
vma = list_first_entry(&unwind_list,
|
|
|
|
struct i915_vma,
|
2011-01-10 14:21:05 +00:00
|
|
|
exec_list);
|
2013-07-17 19:19:03 +00:00
|
|
|
ret = drm_mm_scan_remove_block(&vma->node);
|
2010-08-07 10:01:24 +00:00
|
|
|
BUG_ON(ret);
|
2011-01-10 14:21:05 +00:00
|
|
|
|
2013-08-14 09:38:34 +00:00
|
|
|
list_del_init(&vma->exec_list);
|
2010-08-07 10:01:24 +00:00
|
|
|
}
|
|
|
|
|
2013-12-09 10:37:24 +00:00
|
|
|
/* Can we unpin some objects such as idle hw contents,
|
|
|
|
* or pending flips?
|
2010-08-07 10:01:24 +00:00
|
|
|
*/
|
2014-02-14 13:01:11 +00:00
|
|
|
if (flags & PIN_NONBLOCK)
|
2014-01-20 10:17:37 +00:00
|
|
|
return -ENOSPC;
|
2013-12-09 10:37:24 +00:00
|
|
|
|
|
|
|
/* Only idle the GPU and repeat the search once */
|
2014-01-20 10:17:37 +00:00
|
|
|
if (pass++ == 0) {
|
|
|
|
ret = i915_gpu_idle(dev);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
i915_gem_retire_requests(dev);
|
|
|
|
goto search_again;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If we still have pending pageflip completions, drop
|
|
|
|
* back to userspace to give our workqueues time to
|
|
|
|
* acquire our locks and unpin the old scanouts.
|
|
|
|
*/
|
|
|
|
return intel_has_pending_fb_unpin(dev) ? -EAGAIN : -ENOSPC;
|
2010-08-07 10:01:24 +00:00
|
|
|
|
|
|
|
found:
|
2010-09-29 21:23:05 +00:00
|
|
|
/* drm_mm doesn't allow any other other operations while
|
|
|
|
* scanning, therefore store to be evicted objects on a
|
|
|
|
* temporary list. */
|
2010-08-07 10:01:24 +00:00
|
|
|
INIT_LIST_HEAD(&eviction_list);
|
2010-09-29 21:23:05 +00:00
|
|
|
while (!list_empty(&unwind_list)) {
|
2013-08-14 09:38:34 +00:00
|
|
|
vma = list_first_entry(&unwind_list,
|
|
|
|
struct i915_vma,
|
2010-11-25 19:32:06 +00:00
|
|
|
exec_list);
|
2013-07-17 19:19:03 +00:00
|
|
|
if (drm_mm_scan_remove_block(&vma->node)) {
|
2013-08-14 09:38:34 +00:00
|
|
|
list_move(&vma->exec_list, &eviction_list);
|
|
|
|
drm_gem_object_reference(&vma->obj->base);
|
2010-09-29 21:23:05 +00:00
|
|
|
continue;
|
|
|
|
}
|
2013-08-14 09:38:34 +00:00
|
|
|
list_del_init(&vma->exec_list);
|
2010-08-07 10:01:24 +00:00
|
|
|
}
|
2010-08-07 10:01:23 +00:00
|
|
|
|
2010-08-07 10:01:24 +00:00
|
|
|
/* Unbinding will emit any required flushes */
|
2010-09-29 21:23:05 +00:00
|
|
|
while (!list_empty(&eviction_list)) {
|
2013-08-16 20:29:33 +00:00
|
|
|
struct drm_gem_object *obj;
|
2013-08-14 09:38:34 +00:00
|
|
|
vma = list_first_entry(&eviction_list,
|
|
|
|
struct i915_vma,
|
2010-11-25 19:32:06 +00:00
|
|
|
exec_list);
|
2013-08-16 20:29:33 +00:00
|
|
|
|
|
|
|
obj = &vma->obj->base;
|
|
|
|
list_del_init(&vma->exec_list);
|
2010-09-29 21:23:05 +00:00
|
|
|
if (ret == 0)
|
2013-08-14 09:38:34 +00:00
|
|
|
ret = i915_vma_unbind(vma);
|
2011-01-10 14:21:05 +00:00
|
|
|
|
2013-08-16 20:29:33 +00:00
|
|
|
drm_gem_object_unreference(obj);
|
2010-08-07 10:01:23 +00:00
|
|
|
}
|
2010-08-07 10:01:24 +00:00
|
|
|
|
2010-09-29 21:23:05 +00:00
|
|
|
return ret;
|
2010-08-07 10:01:23 +00:00
|
|
|
}
|
|
|
|
|
2013-09-11 21:57:50 +00:00
|
|
|
/**
|
2014-01-29 21:07:11 +00:00
|
|
|
* i915_gem_evict_vm - Evict all idle vmas from a vm
|
2013-09-11 21:57:50 +00:00
|
|
|
*
|
2014-01-29 21:07:11 +00:00
|
|
|
* @vm: Address space to cleanse
|
2013-09-11 21:57:50 +00:00
|
|
|
* @do_idle: Boolean directing whether to idle first.
|
|
|
|
*
|
2014-01-29 21:07:11 +00:00
|
|
|
* This function evicts all idles vmas from a vm. If all unpinned vmas should be
|
|
|
|
* evicted the @do_idle needs to be set to true.
|
2013-09-11 21:57:50 +00:00
|
|
|
*
|
2014-01-29 21:07:11 +00: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-11 21:57:50 +00:00
|
|
|
*/
|
|
|
|
int i915_gem_evict_vm(struct i915_address_space *vm, bool do_idle)
|
2013-09-11 21:57:49 +00:00
|
|
|
{
|
|
|
|
struct i915_vma *vma, *next;
|
|
|
|
int ret;
|
|
|
|
|
2013-09-24 16:57:56 +00:00
|
|
|
trace_i915_gem_evict_vm(vm);
|
|
|
|
|
2013-09-11 21:57:49 +00:00
|
|
|
if (do_idle) {
|
|
|
|
ret = i915_gpu_idle(vm->dev);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
i915_gem_retire_requests(vm->dev);
|
|
|
|
}
|
|
|
|
|
|
|
|
list_for_each_entry_safe(vma, next, &vm->inactive_list, mm_list)
|
2013-12-06 22:10:55 +00:00
|
|
|
if (vma->pin_count == 0)
|
2013-09-11 21:57:49 +00:00
|
|
|
WARN_ON(i915_vma_unbind(vma));
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-01-29 21:07:11 +00:00
|
|
|
/**
|
|
|
|
* i915_gem_evict_everything - Try to evict all objects
|
|
|
|
* @dev: Device to evict objects for
|
|
|
|
*
|
|
|
|
* This functions tries to evict all gem objects from all address spaces. Used
|
|
|
|
* by the shrinker as a last-ditch effort and for suspend, before releasing the
|
|
|
|
* backing storage of all unbound objects.
|
|
|
|
*/
|
2010-08-07 10:01:23 +00:00
|
|
|
int
|
drm/i915: Track unbound pages
When dealing with a working set larger than the GATT, or even the
mappable aperture when touching through the GTT, we end up with evicting
objects only to rebind them at a new offset again later. Moving an
object into and out of the GTT requires clflushing the pages, thus
causing a double-clflush penalty for rebinding.
To avoid having to clflush on rebinding, we can track the pages as they
are evicted from the GTT and only relinquish those pages on memory
pressure.
As usual, if it were not for the handling of out-of-memory condition and
having to manually shrink our own bo caches, it would be a net reduction
of code. Alas.
Note: The patch also contains a few changes to the last-hope
evict_everything logic in i916_gem_execbuffer.c - we no longer try to
only evict the purgeable stuff in a first try (since that's superflous
and only helps in OOM corner-cases, not fragmented-gtt trashing
situations).
Also, the extraction of the get_pages retry loop from bind_to_gtt (and
other callsites) to get_pages should imo have been a separate patch.
v2: Ditch the newly added put_pages (for unbound objects only) in
i915_gem_reset. A quick irc discussion hasn't revealed any important
reason for this, so if we need this, I'd like to have a git blame'able
explanation for it.
v3: Undo the s/drm_malloc_ab/kmalloc/ in get_pages that Chris noticed.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Split out code movements and rant a bit in the commit message
with a few Notes. Done v2]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-20 09:40:46 +00:00
|
|
|
i915_gem_evict_everything(struct drm_device *dev)
|
2010-08-07 10:01:23 +00:00
|
|
|
{
|
2014-03-31 11:27:21 +00:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2014-09-09 12:04:43 +00:00
|
|
|
struct i915_address_space *vm, *v;
|
2013-08-01 00:00:11 +00:00
|
|
|
bool lists_empty = true;
|
2012-05-11 13:29:30 +00:00
|
|
|
int ret;
|
2010-08-07 10:01:23 +00:00
|
|
|
|
2013-08-01 00:00:11 +00:00
|
|
|
list_for_each_entry(vm, &dev_priv->vm_list, global_link) {
|
|
|
|
lists_empty = (list_empty(&vm->inactive_list) &&
|
|
|
|
list_empty(&vm->active_list));
|
|
|
|
if (!lists_empty)
|
|
|
|
lists_empty = false;
|
|
|
|
}
|
|
|
|
|
2010-08-07 10:01:23 +00:00
|
|
|
if (lists_empty)
|
|
|
|
return -ENOSPC;
|
|
|
|
|
drm/i915: Track unbound pages
When dealing with a working set larger than the GATT, or even the
mappable aperture when touching through the GTT, we end up with evicting
objects only to rebind them at a new offset again later. Moving an
object into and out of the GTT requires clflushing the pages, thus
causing a double-clflush penalty for rebinding.
To avoid having to clflush on rebinding, we can track the pages as they
are evicted from the GTT and only relinquish those pages on memory
pressure.
As usual, if it were not for the handling of out-of-memory condition and
having to manually shrink our own bo caches, it would be a net reduction
of code. Alas.
Note: The patch also contains a few changes to the last-hope
evict_everything logic in i916_gem_execbuffer.c - we no longer try to
only evict the purgeable stuff in a first try (since that's superflous
and only helps in OOM corner-cases, not fragmented-gtt trashing
situations).
Also, the extraction of the get_pages retry loop from bind_to_gtt (and
other callsites) to get_pages should imo have been a separate patch.
v2: Ditch the newly added put_pages (for unbound objects only) in
i915_gem_reset. A quick irc discussion hasn't revealed any important
reason for this, so if we need this, I'd like to have a git blame'able
explanation for it.
v3: Undo the s/drm_malloc_ab/kmalloc/ in get_pages that Chris noticed.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Split out code movements and rant a bit in the commit message
with a few Notes. Done v2]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-20 09:40:46 +00:00
|
|
|
trace_i915_gem_evict_everything(dev);
|
2011-02-03 11:57:46 +00:00
|
|
|
|
2012-04-26 23:02:58 +00:00
|
|
|
/* The gpu_idle will flush everything in the write domain to the
|
|
|
|
* active list. Then we must move everything off the active list
|
|
|
|
* with retire requests.
|
|
|
|
*/
|
2012-05-11 13:29:30 +00:00
|
|
|
ret = i915_gpu_idle(dev);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2012-04-26 23:02:58 +00:00
|
|
|
|
|
|
|
i915_gem_retire_requests(dev);
|
|
|
|
|
2012-04-24 17:22:52 +00:00
|
|
|
/* Having flushed everything, unbind() should never raise an error */
|
2014-09-09 12:04:43 +00:00
|
|
|
list_for_each_entry_safe(vm, v, &dev_priv->vm_list, global_link)
|
2013-09-11 21:57:49 +00:00
|
|
|
WARN_ON(i915_gem_evict_vm(vm, false));
|
2010-08-07 10:01:23 +00:00
|
|
|
|
2012-05-11 13:29:30 +00:00
|
|
|
return 0;
|
2010-08-07 10:01:23 +00:00
|
|
|
}
|