2008-07-31 02:06:12 +07:00
|
|
|
/*
|
|
|
|
* Copyright © 2008 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>
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
2012-10-03 00:01:07 +07:00
|
|
|
#include <drm/drmP.h>
|
2013-07-25 02:07:52 +07:00
|
|
|
#include <drm/drm_vma_manager.h>
|
2012-10-03 00:01:07 +07:00
|
|
|
#include <drm/i915_drm.h>
|
2008-07-31 02:06:12 +07:00
|
|
|
#include "i915_drv.h"
|
2009-08-25 17:15:50 +07:00
|
|
|
#include "i915_trace.h"
|
2009-08-18 03:31:43 +07:00
|
|
|
#include "intel_drv.h"
|
2011-06-28 06:18:18 +07:00
|
|
|
#include <linux/shmem_fs.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 15:04:11 +07:00
|
|
|
#include <linux/slab.h>
|
2008-07-31 02:06:12 +07:00
|
|
|
#include <linux/swap.h>
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
#include <linux/pci.h>
|
2012-05-10 20:25:09 +07:00
|
|
|
#include <linux/dma-buf.h>
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
static void i915_gem_object_flush_gtt_write_domain(struct drm_i915_gem_object *obj);
|
2013-08-09 18:26:45 +07:00
|
|
|
static void i915_gem_object_flush_cpu_write_domain(struct drm_i915_gem_object *obj,
|
|
|
|
bool force);
|
drm/i915: plumb VM into bind/unbind code
As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).
This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.
> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-01 07:00:10 +07:00
|
|
|
static __must_check int
|
2013-09-12 04:57:48 +07:00
|
|
|
i915_gem_object_wait_rendering(struct drm_i915_gem_object *obj,
|
|
|
|
bool readonly);
|
|
|
|
static __must_check int
|
drm/i915: plumb VM into bind/unbind code
As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).
This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.
> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-01 07:00:10 +07:00
|
|
|
i915_gem_object_bind_to_vm(struct drm_i915_gem_object *obj,
|
|
|
|
struct i915_address_space *vm,
|
|
|
|
unsigned alignment,
|
|
|
|
bool map_and_fenceable,
|
|
|
|
bool nonblocking);
|
2010-11-09 02:18:58 +07:00
|
|
|
static int i915_gem_phys_pwrite(struct drm_device *dev,
|
|
|
|
struct drm_i915_gem_object *obj,
|
2008-12-30 17:31:46 +07:00
|
|
|
struct drm_i915_gem_pwrite *args,
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_file *file);
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2012-04-17 21:31:31 +07:00
|
|
|
static void i915_gem_write_fence(struct drm_device *dev, int reg,
|
|
|
|
struct drm_i915_gem_object *obj);
|
|
|
|
static void i915_gem_object_update_fence(struct drm_i915_gem_object *obj,
|
|
|
|
struct drm_i915_fence_reg *fence,
|
|
|
|
bool enable);
|
|
|
|
|
drivers: convert shrinkers to new count/scan API
Convert the driver shrinkers to the new API. Most changes are compile
tested only because I either don't have the hardware or it's staging
stuff.
FWIW, the md and android code is pretty good, but the rest of it makes me
want to claw my eyes out. The amount of broken code I just encountered is
mind boggling. I've added comments explaining what is broken, but I fear
that some of the code would be best dealt with by being dragged behind the
bike shed, burying in mud up to it's neck and then run over repeatedly
with a blunt lawn mower.
Special mention goes to the zcache/zcache2 drivers. They can't co-exist
in the build at the same time, they are under different menu options in
menuconfig, they only show up when you've got the right set of mm
subsystem options configured and so even compile testing is an exercise in
pulling teeth. And that doesn't even take into account the horrible,
broken code...
[glommer@openvz.org: fixes for i915, android lowmem, zcache, bcache]
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Glauber Costa <glommer@openvz.org>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Rientjes <rientjes@google.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: J. Bruce Fields <bfields@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-28 07:18:11 +07:00
|
|
|
static unsigned long i915_gem_inactive_count(struct shrinker *shrinker,
|
|
|
|
struct shrink_control *sc);
|
|
|
|
static unsigned long i915_gem_inactive_scan(struct shrinker *shrinker,
|
|
|
|
struct shrink_control *sc);
|
2013-10-04 16:33:00 +07:00
|
|
|
static unsigned long i915_gem_purge(struct drm_i915_private *dev_priv, long target);
|
|
|
|
static unsigned long i915_gem_shrink_all(struct drm_i915_private *dev_priv);
|
drm/i915: rewrite shmem_pwrite_slow to use copy_from_user
... instead of get_user_pages, because that fails on non page-backed
user addresses like e.g. a gtt mapping of a bo.
To get there essentially copy the vfs read path into pagecache. We
can't call that right away because we have to take care of bit17
swizzling. To not deadlock with our own pagefault handler we need
to completely drop struct_mutex, reducing the atomicty-guarantees
of our userspace abi. Implications for racing with other gem ioctl:
- execbuf, pwrite, pread: Due to -EFAULT fallback to slow paths there's
already the risk of the pwrite call not being atomic, no degration.
- read/write access to mmaps: already fully racy, no degration.
- set_tiling: Calling set_tiling while reading/writing is already
pretty much undefined, now it just got a bit worse. set_tiling is
only called by libdrm on unused/new bos, so no problem.
- set_domain: When changing to the gtt domain while copying (without any
read/write access, e.g. for synchronization), we might leave unflushed
data in the cpu caches. The clflush_object at the end of pwrite_slow
takes care of this problem.
- truncating of purgeable objects: the shmem_read_mapping_page call could
reinstate backing storage for truncated objects. The check at the end
of pwrite_slow takes care of this.
v2:
- add missing intel_gtt_chipset_flush
- add __ to copy_from_user_swizzled as suggest by Chris Wilson.
v3: Fixup bit17 swizzling, it swizzled the wrong pages.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2011-12-14 19:57:31 +07:00
|
|
|
static void i915_gem_object_truncate(struct drm_i915_gem_object *obj);
|
2009-09-14 22:50:28 +07:00
|
|
|
|
2013-08-08 20:41:03 +07:00
|
|
|
static bool cpu_cache_is_coherent(struct drm_device *dev,
|
|
|
|
enum i915_cache_level level)
|
|
|
|
{
|
|
|
|
return HAS_LLC(dev) || level != I915_CACHE_NONE;
|
|
|
|
}
|
|
|
|
|
2013-08-09 18:26:45 +07:00
|
|
|
static bool cpu_write_needs_clflush(struct drm_i915_gem_object *obj)
|
|
|
|
{
|
|
|
|
if (!cpu_cache_is_coherent(obj->base.dev, obj->cache_level))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return obj->pin_display;
|
|
|
|
}
|
|
|
|
|
2012-04-17 21:31:31 +07:00
|
|
|
static inline void i915_gem_object_fence_lost(struct drm_i915_gem_object *obj)
|
|
|
|
{
|
|
|
|
if (obj->tiling_mode)
|
|
|
|
i915_gem_release_mmap(obj);
|
|
|
|
|
|
|
|
/* As we do not have an associated fence register, we will force
|
|
|
|
* a tiling change if we ever need to acquire one.
|
|
|
|
*/
|
2012-04-21 22:23:23 +07:00
|
|
|
obj->fence_dirty = false;
|
2012-04-17 21:31:31 +07:00
|
|
|
obj->fence_reg = I915_FENCE_REG_NONE;
|
|
|
|
}
|
|
|
|
|
2010-09-30 17:46:12 +07:00
|
|
|
/* some bookkeeping */
|
|
|
|
static void i915_gem_info_add_obj(struct drm_i915_private *dev_priv,
|
|
|
|
size_t size)
|
|
|
|
{
|
2013-07-25 03:40:23 +07:00
|
|
|
spin_lock(&dev_priv->mm.object_stat_lock);
|
2010-09-30 17:46:12 +07:00
|
|
|
dev_priv->mm.object_count++;
|
|
|
|
dev_priv->mm.object_memory += size;
|
2013-07-25 03:40:23 +07:00
|
|
|
spin_unlock(&dev_priv->mm.object_stat_lock);
|
2010-09-30 17:46:12 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void i915_gem_info_remove_obj(struct drm_i915_private *dev_priv,
|
|
|
|
size_t size)
|
|
|
|
{
|
2013-07-25 03:40:23 +07:00
|
|
|
spin_lock(&dev_priv->mm.object_stat_lock);
|
2010-09-30 17:46:12 +07:00
|
|
|
dev_priv->mm.object_count--;
|
|
|
|
dev_priv->mm.object_memory -= size;
|
2013-07-25 03:40:23 +07:00
|
|
|
spin_unlock(&dev_priv->mm.object_stat_lock);
|
2010-09-30 17:46:12 +07:00
|
|
|
}
|
|
|
|
|
2011-01-26 22:55:56 +07:00
|
|
|
static int
|
2012-11-14 23:14:05 +07:00
|
|
|
i915_gem_wait_for_error(struct i915_gpu_error *error)
|
2010-09-25 16:19:17 +07:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2013-05-25 02:29:32 +07:00
|
|
|
#define EXIT_COND (!i915_reset_in_progress(error) || \
|
|
|
|
i915_terminally_wedged(error))
|
2012-11-15 23:17:22 +07:00
|
|
|
if (EXIT_COND)
|
2010-09-25 16:19:17 +07:00
|
|
|
return 0;
|
|
|
|
|
2012-07-05 03:18:41 +07:00
|
|
|
/*
|
|
|
|
* Only wait 10 seconds for the gpu reset to complete to avoid hanging
|
|
|
|
* userspace. If it takes that long something really bad is going on and
|
|
|
|
* we should simply try to bail out and fail as gracefully as possible.
|
|
|
|
*/
|
2012-11-15 23:17:22 +07:00
|
|
|
ret = wait_event_interruptible_timeout(error->reset_queue,
|
|
|
|
EXIT_COND,
|
|
|
|
10*HZ);
|
2012-07-05 03:18:41 +07:00
|
|
|
if (ret == 0) {
|
|
|
|
DRM_ERROR("Timed out waiting for the gpu reset to complete\n");
|
|
|
|
return -EIO;
|
|
|
|
} else if (ret < 0) {
|
2010-09-25 16:19:17 +07:00
|
|
|
return ret;
|
2012-07-05 03:18:41 +07:00
|
|
|
}
|
2012-11-15 23:17:22 +07:00
|
|
|
#undef EXIT_COND
|
2010-09-25 16:19:17 +07:00
|
|
|
|
2011-01-26 22:55:56 +07:00
|
|
|
return 0;
|
2010-09-25 16:19:17 +07:00
|
|
|
}
|
|
|
|
|
2010-11-26 01:00:26 +07:00
|
|
|
int i915_mutex_lock_interruptible(struct drm_device *dev)
|
2010-09-25 17:22:51 +07:00
|
|
|
{
|
2012-11-14 23:14:05 +07:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2010-09-25 17:22:51 +07:00
|
|
|
int ret;
|
|
|
|
|
2012-11-14 23:14:05 +07:00
|
|
|
ret = i915_gem_wait_for_error(&dev_priv->gpu_error);
|
2010-09-25 17:22:51 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ret = mutex_lock_interruptible(&dev->struct_mutex);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2010-09-29 22:10:57 +07:00
|
|
|
WARN_ON(i915_verify_lists(dev));
|
2010-09-25 17:22:51 +07:00
|
|
|
return 0;
|
|
|
|
}
|
2010-09-25 16:19:17 +07:00
|
|
|
|
2010-08-08 03:45:03 +07:00
|
|
|
static inline bool
|
2010-11-09 02:18:58 +07:00
|
|
|
i915_gem_object_is_inactive(struct drm_i915_gem_object *obj)
|
2010-08-08 03:45:03 +07:00
|
|
|
{
|
2013-08-01 07:00:12 +07:00
|
|
|
return i915_gem_obj_bound_any(obj) && !obj->active;
|
2010-08-08 03:45:03 +07:00
|
|
|
}
|
|
|
|
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
int
|
|
|
|
i915_gem_init_ioctl(struct drm_device *dev, void *data,
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_file *file)
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
{
|
2013-01-18 03:45:17 +07:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
struct drm_i915_gem_init *args = data;
|
2010-11-23 22:26:33 +07:00
|
|
|
|
2012-04-24 13:22:52 +07:00
|
|
|
if (drm_core_check_feature(dev, DRIVER_MODESET))
|
|
|
|
return -ENODEV;
|
|
|
|
|
2010-11-23 22:26:33 +07:00
|
|
|
if (args->gtt_start >= args->gtt_end ||
|
|
|
|
(args->gtt_end | args->gtt_start) & (PAGE_SIZE - 1))
|
|
|
|
return -EINVAL;
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
|
2012-03-27 03:37:04 +07:00
|
|
|
/* GEM with user mode setting was never supported on ilk and later. */
|
|
|
|
if (INTEL_INFO(dev)->gen >= 5)
|
|
|
|
return -ENODEV;
|
|
|
|
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
mutex_lock(&dev->struct_mutex);
|
2012-12-19 01:31:25 +07:00
|
|
|
i915_gem_setup_global_gtt(dev, args->gtt_start, args->gtt_end,
|
|
|
|
args->gtt_end);
|
2013-01-18 03:45:17 +07:00
|
|
|
dev_priv->gtt.mappable_end = args->gtt_end;
|
2008-07-31 02:06:12 +07:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
|
2010-11-23 22:26:33 +07:00
|
|
|
return 0;
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
2008-10-23 11:40:13 +07:00
|
|
|
int
|
|
|
|
i915_gem_get_aperture_ioctl(struct drm_device *dev, void *data,
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_file *file)
|
2008-10-23 11:40:13 +07:00
|
|
|
{
|
2010-09-30 17:46:12 +07:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2008-10-23 11:40:13 +07:00
|
|
|
struct drm_i915_gem_get_aperture *args = data;
|
2010-11-24 19:23:44 +07:00
|
|
|
struct drm_i915_gem_object *obj;
|
|
|
|
size_t pinned;
|
2008-10-23 11:40:13 +07:00
|
|
|
|
2010-11-24 19:23:44 +07:00
|
|
|
pinned = 0;
|
2010-09-30 17:46:12 +07:00
|
|
|
mutex_lock(&dev->struct_mutex);
|
2013-06-01 01:28:48 +07:00
|
|
|
list_for_each_entry(obj, &dev_priv->mm.bound_list, global_list)
|
2012-04-24 21:47:30 +07:00
|
|
|
if (obj->pin_count)
|
2013-07-06 04:41:04 +07:00
|
|
|
pinned += i915_gem_obj_ggtt_size(obj);
|
2010-09-30 17:46:12 +07:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
2008-10-23 11:40:13 +07:00
|
|
|
|
2013-07-17 06:50:05 +07:00
|
|
|
args->aper_size = dev_priv->gtt.base.total;
|
2011-08-17 02:34:10 +07:00
|
|
|
args->aper_available_size = args->aper_size - pinned;
|
2010-11-24 19:23:44 +07:00
|
|
|
|
2008-10-23 11:40:13 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-11-15 18:32:30 +07:00
|
|
|
void *i915_gem_object_alloc(struct drm_device *dev)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2013-08-30 03:11:07 +07:00
|
|
|
return kmem_cache_zalloc(dev_priv->slab, GFP_KERNEL);
|
2012-11-15 18:32:30 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
void i915_gem_object_free(struct drm_i915_gem_object *obj)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
|
|
|
|
kmem_cache_free(dev_priv->slab, obj);
|
|
|
|
}
|
|
|
|
|
2011-02-07 09:16:14 +07:00
|
|
|
static int
|
|
|
|
i915_gem_create(struct drm_file *file,
|
|
|
|
struct drm_device *dev,
|
|
|
|
uint64_t size,
|
|
|
|
uint32_t *handle_p)
|
2008-07-31 02:06:12 +07:00
|
|
|
{
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_i915_gem_object *obj;
|
2009-08-23 16:40:55 +07:00
|
|
|
int ret;
|
|
|
|
u32 handle;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2011-02-07 09:16:14 +07:00
|
|
|
size = roundup(size, PAGE_SIZE);
|
2011-09-14 19:14:28 +07:00
|
|
|
if (size == 0)
|
|
|
|
return -EINVAL;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
|
|
|
/* Allocate the new object */
|
2011-02-07 09:16:14 +07:00
|
|
|
obj = i915_gem_alloc_object(dev, size);
|
2008-07-31 02:06:12 +07:00
|
|
|
if (obj == NULL)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
ret = drm_gem_handle_create(file, &obj->base, &handle);
|
2010-10-14 19:20:40 +07:00
|
|
|
/* drop reference from allocate - handle holds it now */
|
2013-07-25 04:25:03 +07:00
|
|
|
drm_gem_object_unreference_unlocked(&obj->base);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2010-10-14 19:20:40 +07:00
|
|
|
|
2011-02-07 09:16:14 +07:00
|
|
|
*handle_p = handle;
|
2008-07-31 02:06:12 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-02-07 09:16:14 +07:00
|
|
|
int
|
|
|
|
i915_gem_dumb_create(struct drm_file *file,
|
|
|
|
struct drm_device *dev,
|
|
|
|
struct drm_mode_create_dumb *args)
|
|
|
|
{
|
|
|
|
/* have to work out size/pitch and return them */
|
2013-10-19 04:48:24 +07:00
|
|
|
args->pitch = ALIGN(args->width * DIV_ROUND_UP(args->bpp, 8), 64);
|
2011-02-07 09:16:14 +07:00
|
|
|
args->size = args->pitch * args->height;
|
|
|
|
return i915_gem_create(file, dev,
|
|
|
|
args->size, &args->handle);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Creates a new mm object and returns a handle to it.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
i915_gem_create_ioctl(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file)
|
|
|
|
{
|
|
|
|
struct drm_i915_gem_create *args = data;
|
2012-04-23 21:50:50 +07:00
|
|
|
|
2011-02-07 09:16:14 +07:00
|
|
|
return i915_gem_create(file, dev,
|
|
|
|
args->size, &args->handle);
|
|
|
|
}
|
|
|
|
|
2011-12-14 19:57:32 +07:00
|
|
|
static inline int
|
|
|
|
__copy_to_user_swizzled(char __user *cpu_vaddr,
|
|
|
|
const char *gpu_vaddr, int gpu_offset,
|
|
|
|
int length)
|
|
|
|
{
|
|
|
|
int ret, cpu_offset = 0;
|
|
|
|
|
|
|
|
while (length > 0) {
|
|
|
|
int cacheline_end = ALIGN(gpu_offset + 1, 64);
|
|
|
|
int this_length = min(cacheline_end - gpu_offset, length);
|
|
|
|
int swizzled_gpu_offset = gpu_offset ^ 64;
|
|
|
|
|
|
|
|
ret = __copy_to_user(cpu_vaddr + cpu_offset,
|
|
|
|
gpu_vaddr + swizzled_gpu_offset,
|
|
|
|
this_length);
|
|
|
|
if (ret)
|
|
|
|
return ret + length;
|
|
|
|
|
|
|
|
cpu_offset += this_length;
|
|
|
|
gpu_offset += this_length;
|
|
|
|
length -= this_length;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
drm/i915: rewrite shmem_pwrite_slow to use copy_from_user
... instead of get_user_pages, because that fails on non page-backed
user addresses like e.g. a gtt mapping of a bo.
To get there essentially copy the vfs read path into pagecache. We
can't call that right away because we have to take care of bit17
swizzling. To not deadlock with our own pagefault handler we need
to completely drop struct_mutex, reducing the atomicty-guarantees
of our userspace abi. Implications for racing with other gem ioctl:
- execbuf, pwrite, pread: Due to -EFAULT fallback to slow paths there's
already the risk of the pwrite call not being atomic, no degration.
- read/write access to mmaps: already fully racy, no degration.
- set_tiling: Calling set_tiling while reading/writing is already
pretty much undefined, now it just got a bit worse. set_tiling is
only called by libdrm on unused/new bos, so no problem.
- set_domain: When changing to the gtt domain while copying (without any
read/write access, e.g. for synchronization), we might leave unflushed
data in the cpu caches. The clflush_object at the end of pwrite_slow
takes care of this problem.
- truncating of purgeable objects: the shmem_read_mapping_page call could
reinstate backing storage for truncated objects. The check at the end
of pwrite_slow takes care of this.
v2:
- add missing intel_gtt_chipset_flush
- add __ to copy_from_user_swizzled as suggest by Chris Wilson.
v3: Fixup bit17 swizzling, it swizzled the wrong pages.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2011-12-14 19:57:31 +07:00
|
|
|
static inline int
|
2012-04-17 04:07:47 +07:00
|
|
|
__copy_from_user_swizzled(char *gpu_vaddr, int gpu_offset,
|
|
|
|
const char __user *cpu_vaddr,
|
drm/i915: rewrite shmem_pwrite_slow to use copy_from_user
... instead of get_user_pages, because that fails on non page-backed
user addresses like e.g. a gtt mapping of a bo.
To get there essentially copy the vfs read path into pagecache. We
can't call that right away because we have to take care of bit17
swizzling. To not deadlock with our own pagefault handler we need
to completely drop struct_mutex, reducing the atomicty-guarantees
of our userspace abi. Implications for racing with other gem ioctl:
- execbuf, pwrite, pread: Due to -EFAULT fallback to slow paths there's
already the risk of the pwrite call not being atomic, no degration.
- read/write access to mmaps: already fully racy, no degration.
- set_tiling: Calling set_tiling while reading/writing is already
pretty much undefined, now it just got a bit worse. set_tiling is
only called by libdrm on unused/new bos, so no problem.
- set_domain: When changing to the gtt domain while copying (without any
read/write access, e.g. for synchronization), we might leave unflushed
data in the cpu caches. The clflush_object at the end of pwrite_slow
takes care of this problem.
- truncating of purgeable objects: the shmem_read_mapping_page call could
reinstate backing storage for truncated objects. The check at the end
of pwrite_slow takes care of this.
v2:
- add missing intel_gtt_chipset_flush
- add __ to copy_from_user_swizzled as suggest by Chris Wilson.
v3: Fixup bit17 swizzling, it swizzled the wrong pages.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2011-12-14 19:57:31 +07:00
|
|
|
int length)
|
|
|
|
{
|
|
|
|
int ret, cpu_offset = 0;
|
|
|
|
|
|
|
|
while (length > 0) {
|
|
|
|
int cacheline_end = ALIGN(gpu_offset + 1, 64);
|
|
|
|
int this_length = min(cacheline_end - gpu_offset, length);
|
|
|
|
int swizzled_gpu_offset = gpu_offset ^ 64;
|
|
|
|
|
|
|
|
ret = __copy_from_user(gpu_vaddr + swizzled_gpu_offset,
|
|
|
|
cpu_vaddr + cpu_offset,
|
|
|
|
this_length);
|
|
|
|
if (ret)
|
|
|
|
return ret + length;
|
|
|
|
|
|
|
|
cpu_offset += this_length;
|
|
|
|
gpu_offset += this_length;
|
|
|
|
length -= this_length;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-03-26 00:47:40 +07:00
|
|
|
/* Per-page copy function for the shmem pread fastpath.
|
|
|
|
* Flushes invalid cachelines before reading the target if
|
|
|
|
* needs_clflush is set. */
|
2009-03-11 01:44:52 +07:00
|
|
|
static int
|
2012-03-26 00:47:40 +07:00
|
|
|
shmem_pread_fast(struct page *page, int shmem_page_offset, int page_length,
|
|
|
|
char __user *user_data,
|
|
|
|
bool page_do_bit17_swizzling, bool needs_clflush)
|
|
|
|
{
|
|
|
|
char *vaddr;
|
|
|
|
int ret;
|
|
|
|
|
2012-03-26 00:47:43 +07:00
|
|
|
if (unlikely(page_do_bit17_swizzling))
|
2012-03-26 00:47:40 +07:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
vaddr = kmap_atomic(page);
|
|
|
|
if (needs_clflush)
|
|
|
|
drm_clflush_virt_range(vaddr + shmem_page_offset,
|
|
|
|
page_length);
|
|
|
|
ret = __copy_to_user_inatomic(user_data,
|
|
|
|
vaddr + shmem_page_offset,
|
|
|
|
page_length);
|
|
|
|
kunmap_atomic(vaddr);
|
|
|
|
|
2012-09-05 03:02:56 +07:00
|
|
|
return ret ? -EFAULT : 0;
|
2012-03-26 00:47:40 +07:00
|
|
|
}
|
|
|
|
|
2012-03-26 00:47:42 +07:00
|
|
|
static void
|
|
|
|
shmem_clflush_swizzled_range(char *addr, unsigned long length,
|
|
|
|
bool swizzled)
|
|
|
|
{
|
2012-03-26 00:47:43 +07:00
|
|
|
if (unlikely(swizzled)) {
|
2012-03-26 00:47:42 +07:00
|
|
|
unsigned long start = (unsigned long) addr;
|
|
|
|
unsigned long end = (unsigned long) addr + length;
|
|
|
|
|
|
|
|
/* For swizzling simply ensure that we always flush both
|
|
|
|
* channels. Lame, but simple and it works. Swizzled
|
|
|
|
* pwrite/pread is far from a hotpath - current userspace
|
|
|
|
* doesn't use it at all. */
|
|
|
|
start = round_down(start, 128);
|
|
|
|
end = round_up(end, 128);
|
|
|
|
|
|
|
|
drm_clflush_virt_range((void *)start, end - start);
|
|
|
|
} else {
|
|
|
|
drm_clflush_virt_range(addr, length);
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2012-03-26 00:47:40 +07:00
|
|
|
/* Only difference to the fast-path function is that this can handle bit17
|
|
|
|
* and uses non-atomic copy and kmap functions. */
|
|
|
|
static int
|
|
|
|
shmem_pread_slow(struct page *page, int shmem_page_offset, int page_length,
|
|
|
|
char __user *user_data,
|
|
|
|
bool page_do_bit17_swizzling, bool needs_clflush)
|
|
|
|
{
|
|
|
|
char *vaddr;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
vaddr = kmap(page);
|
|
|
|
if (needs_clflush)
|
2012-03-26 00:47:42 +07:00
|
|
|
shmem_clflush_swizzled_range(vaddr + shmem_page_offset,
|
|
|
|
page_length,
|
|
|
|
page_do_bit17_swizzling);
|
2012-03-26 00:47:40 +07:00
|
|
|
|
|
|
|
if (page_do_bit17_swizzling)
|
|
|
|
ret = __copy_to_user_swizzled(user_data,
|
|
|
|
vaddr, shmem_page_offset,
|
|
|
|
page_length);
|
|
|
|
else
|
|
|
|
ret = __copy_to_user(user_data,
|
|
|
|
vaddr + shmem_page_offset,
|
|
|
|
page_length);
|
|
|
|
kunmap(page);
|
|
|
|
|
2012-09-05 03:02:56 +07:00
|
|
|
return ret ? - EFAULT : 0;
|
2012-03-26 00:47:40 +07:00
|
|
|
}
|
|
|
|
|
2009-03-11 01:44:52 +07:00
|
|
|
static int
|
2012-03-26 00:47:29 +07:00
|
|
|
i915_gem_shmem_pread(struct drm_device *dev,
|
|
|
|
struct drm_i915_gem_object *obj,
|
|
|
|
struct drm_i915_gem_pread *args,
|
|
|
|
struct drm_file *file)
|
2009-03-11 01:44:52 +07:00
|
|
|
{
|
2011-12-14 19:57:32 +07:00
|
|
|
char __user *user_data;
|
2009-03-11 01:44:52 +07:00
|
|
|
ssize_t remain;
|
2011-12-14 19:57:32 +07:00
|
|
|
loff_t offset;
|
2012-02-15 20:42:43 +07:00
|
|
|
int shmem_page_offset, page_length, ret = 0;
|
2011-12-14 19:57:32 +07:00
|
|
|
int obj_do_bit17_swizzling, page_do_bit17_swizzling;
|
2012-03-26 00:47:36 +07:00
|
|
|
int prefaulted = 0;
|
2012-03-26 00:47:31 +07:00
|
|
|
int needs_clflush = 0;
|
2013-02-19 00:28:02 +07:00
|
|
|
struct sg_page_iter sg_iter;
|
2009-03-11 01:44:52 +07:00
|
|
|
|
2013-02-22 21:12:51 +07:00
|
|
|
user_data = to_user_ptr(args->data_ptr);
|
2009-03-11 01:44:52 +07:00
|
|
|
remain = args->size;
|
|
|
|
|
2011-12-14 19:57:32 +07:00
|
|
|
obj_do_bit17_swizzling = i915_gem_object_needs_bit17_swizzle(obj);
|
2009-03-11 01:44:52 +07:00
|
|
|
|
2012-03-26 00:47:31 +07:00
|
|
|
if (!(obj->base.read_domains & I915_GEM_DOMAIN_CPU)) {
|
|
|
|
/* If we're not in the cpu read domain, set ourself into the gtt
|
|
|
|
* read domain and manually flush cachelines (if required). This
|
|
|
|
* optimizes for the case when the gpu will dirty the data
|
|
|
|
* anyway again before the next pread happens. */
|
2013-08-08 20:41:03 +07:00
|
|
|
needs_clflush = !cpu_cache_is_coherent(dev, obj->cache_level);
|
2013-09-12 04:57:48 +07:00
|
|
|
ret = i915_gem_object_wait_rendering(obj, true);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2012-03-26 00:47:31 +07:00
|
|
|
}
|
2009-03-11 01:44:52 +07:00
|
|
|
|
2012-09-05 03:02:56 +07:00
|
|
|
ret = i915_gem_object_get_pages(obj);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
i915_gem_object_pin_pages(obj);
|
|
|
|
|
2011-12-14 19:57:32 +07:00
|
|
|
offset = args->offset;
|
2009-03-11 01:44:52 +07:00
|
|
|
|
2013-02-19 00:28:02 +07:00
|
|
|
for_each_sg_page(obj->pages->sgl, &sg_iter, obj->pages->nents,
|
|
|
|
offset >> PAGE_SHIFT) {
|
2013-03-26 20:14:18 +07:00
|
|
|
struct page *page = sg_page_iter_page(&sg_iter);
|
2012-06-01 21:20:22 +07:00
|
|
|
|
|
|
|
if (remain <= 0)
|
|
|
|
break;
|
|
|
|
|
2009-03-11 01:44:52 +07:00
|
|
|
/* Operation in this page
|
|
|
|
*
|
|
|
|
* shmem_page_offset = offset within page in shmem file
|
|
|
|
* page_length = bytes to copy for this page
|
|
|
|
*/
|
2011-05-13 04:17:11 +07:00
|
|
|
shmem_page_offset = offset_in_page(offset);
|
2009-03-11 01:44:52 +07:00
|
|
|
page_length = remain;
|
|
|
|
if ((shmem_page_offset + page_length) > PAGE_SIZE)
|
|
|
|
page_length = PAGE_SIZE - shmem_page_offset;
|
|
|
|
|
2011-12-14 19:57:32 +07:00
|
|
|
page_do_bit17_swizzling = obj_do_bit17_swizzling &&
|
|
|
|
(page_to_phys(page) & (1 << 17)) != 0;
|
|
|
|
|
2012-03-26 00:47:40 +07:00
|
|
|
ret = shmem_pread_fast(page, shmem_page_offset, page_length,
|
|
|
|
user_data, page_do_bit17_swizzling,
|
|
|
|
needs_clflush);
|
|
|
|
if (ret == 0)
|
|
|
|
goto next_page;
|
2012-03-26 00:47:29 +07:00
|
|
|
|
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
|
2013-07-19 12:51:24 +07:00
|
|
|
if (likely(!i915_prefault_disable) && !prefaulted) {
|
2012-03-26 00:47:41 +07:00
|
|
|
ret = fault_in_multipages_writeable(user_data, remain);
|
2012-03-26 00:47:36 +07:00
|
|
|
/* Userspace is tricking us, but we've already clobbered
|
|
|
|
* its pages with the prefault and promised to write the
|
|
|
|
* data up to the first fault. Hence ignore any errors
|
|
|
|
* and just continue. */
|
|
|
|
(void)ret;
|
|
|
|
prefaulted = 1;
|
|
|
|
}
|
2009-03-11 01:44:52 +07:00
|
|
|
|
2012-03-26 00:47:40 +07:00
|
|
|
ret = shmem_pread_slow(page, shmem_page_offset, page_length,
|
|
|
|
user_data, page_do_bit17_swizzling,
|
|
|
|
needs_clflush);
|
2009-03-11 01:44:52 +07:00
|
|
|
|
2012-03-26 00:47:29 +07:00
|
|
|
mutex_lock(&dev->struct_mutex);
|
2012-09-05 03:02:56 +07:00
|
|
|
|
2012-03-26 00:47:29 +07:00
|
|
|
next_page:
|
2010-10-28 19:45:36 +07:00
|
|
|
mark_page_accessed(page);
|
|
|
|
|
2012-09-05 03:02:56 +07:00
|
|
|
if (ret)
|
2011-12-14 19:57:32 +07:00
|
|
|
goto out;
|
|
|
|
|
2009-03-11 01:44:52 +07:00
|
|
|
remain -= page_length;
|
2011-12-14 19:57:32 +07:00
|
|
|
user_data += page_length;
|
2009-03-11 01:44:52 +07:00
|
|
|
offset += page_length;
|
|
|
|
}
|
|
|
|
|
2010-10-14 21:26:45 +07:00
|
|
|
out:
|
2012-09-05 03:02:56 +07:00
|
|
|
i915_gem_object_unpin_pages(obj);
|
|
|
|
|
2009-03-11 01:44:52 +07:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2008-07-31 02:06:12 +07:00
|
|
|
/**
|
|
|
|
* Reads data from the object referenced by handle.
|
|
|
|
*
|
|
|
|
* On error, the contents of *data are undefined.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
i915_gem_pread_ioctl(struct drm_device *dev, void *data,
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_file *file)
|
2008-07-31 02:06:12 +07:00
|
|
|
{
|
|
|
|
struct drm_i915_gem_pread *args = data;
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_i915_gem_object *obj;
|
2010-09-27 02:23:38 +07:00
|
|
|
int ret = 0;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2010-11-17 16:10:42 +07:00
|
|
|
if (args->size == 0)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (!access_ok(VERIFY_WRITE,
|
2013-02-22 21:12:51 +07:00
|
|
|
to_user_ptr(args->data_ptr),
|
2010-11-17 16:10:42 +07:00
|
|
|
args->size))
|
|
|
|
return -EFAULT;
|
|
|
|
|
2010-10-14 21:26:45 +07:00
|
|
|
ret = i915_mutex_lock_interruptible(dev);
|
2010-10-17 15:45:41 +07:00
|
|
|
if (ret)
|
2010-10-14 21:26:45 +07:00
|
|
|
return ret;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
obj = to_intel_bo(drm_gem_object_lookup(dev, file, args->handle));
|
2011-02-19 18:31:06 +07:00
|
|
|
if (&obj->base == NULL) {
|
2010-10-17 15:45:41 +07:00
|
|
|
ret = -ENOENT;
|
|
|
|
goto unlock;
|
2010-10-14 21:26:45 +07:00
|
|
|
}
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2010-09-27 02:21:44 +07:00
|
|
|
/* Bounds check source. */
|
2010-11-09 02:18:58 +07:00
|
|
|
if (args->offset > obj->base.size ||
|
|
|
|
args->size > obj->base.size - args->offset) {
|
2010-09-27 02:50:05 +07:00
|
|
|
ret = -EINVAL;
|
2010-09-27 02:23:38 +07:00
|
|
|
goto out;
|
2010-09-27 02:50:05 +07:00
|
|
|
}
|
|
|
|
|
2012-05-10 20:25:09 +07:00
|
|
|
/* prime objects have no backing filp to GEM pread/pwrite
|
|
|
|
* pages from.
|
|
|
|
*/
|
|
|
|
if (!obj->base.filp) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2011-02-03 18:57:46 +07:00
|
|
|
trace_i915_gem_object_pread(obj, args->offset, args->size);
|
|
|
|
|
2012-03-26 00:47:29 +07:00
|
|
|
ret = i915_gem_shmem_pread(dev, obj, args, file);
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2010-09-27 02:23:38 +07:00
|
|
|
out:
|
2010-11-09 02:18:58 +07:00
|
|
|
drm_gem_object_unreference(&obj->base);
|
2010-10-17 15:45:41 +07:00
|
|
|
unlock:
|
2010-10-14 21:26:45 +07:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
2009-03-11 01:44:52 +07:00
|
|
|
return ret;
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
2008-10-31 09:38:48 +07:00
|
|
|
/* This is the fast write path which cannot handle
|
|
|
|
* page faults in the source data
|
2008-10-21 04:16:43 +07:00
|
|
|
*/
|
2008-10-31 09:38:48 +07:00
|
|
|
|
|
|
|
static inline int
|
|
|
|
fast_user_write(struct io_mapping *mapping,
|
|
|
|
loff_t page_base, int page_offset,
|
|
|
|
char __user *user_data,
|
|
|
|
int length)
|
2008-10-21 04:16:43 +07:00
|
|
|
{
|
2012-04-17 04:07:47 +07:00
|
|
|
void __iomem *vaddr_atomic;
|
|
|
|
void *vaddr;
|
2008-10-31 09:38:48 +07:00
|
|
|
unsigned long unwritten;
|
2008-10-21 04:16:43 +07:00
|
|
|
|
2010-10-27 04:21:51 +07:00
|
|
|
vaddr_atomic = io_mapping_map_atomic_wc(mapping, page_base);
|
2012-04-17 04:07:47 +07:00
|
|
|
/* We can use the cpu mem copy function because this is X86. */
|
|
|
|
vaddr = (void __force*)vaddr_atomic + page_offset;
|
|
|
|
unwritten = __copy_from_user_inatomic_nocache(vaddr,
|
2008-10-31 09:38:48 +07:00
|
|
|
user_data, length);
|
2010-10-27 04:21:51 +07:00
|
|
|
io_mapping_unmap_atomic(vaddr_atomic);
|
2010-10-14 21:03:58 +07:00
|
|
|
return unwritten;
|
2008-10-31 09:38:48 +07:00
|
|
|
}
|
|
|
|
|
2009-03-09 23:42:23 +07:00
|
|
|
/**
|
|
|
|
* This is the fast pwrite path, where we copy the data directly from the
|
|
|
|
* user into the GTT, uncached.
|
|
|
|
*/
|
2008-07-31 02:06:12 +07:00
|
|
|
static int
|
2010-11-09 02:18:58 +07:00
|
|
|
i915_gem_gtt_pwrite_fast(struct drm_device *dev,
|
|
|
|
struct drm_i915_gem_object *obj,
|
2009-03-09 23:42:23 +07:00
|
|
|
struct drm_i915_gem_pwrite *args,
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_file *file)
|
2008-07-31 02:06:12 +07:00
|
|
|
{
|
2008-10-31 09:38:48 +07:00
|
|
|
drm_i915_private_t *dev_priv = dev->dev_private;
|
2008-07-31 02:06:12 +07:00
|
|
|
ssize_t remain;
|
2008-10-31 09:38:48 +07:00
|
|
|
loff_t offset, page_base;
|
2008-07-31 02:06:12 +07:00
|
|
|
char __user *user_data;
|
2012-03-26 00:47:35 +07:00
|
|
|
int page_offset, page_length, ret;
|
|
|
|
|
2013-08-01 06:59:58 +07:00
|
|
|
ret = i915_gem_obj_ggtt_pin(obj, 0, true, true);
|
2012-03-26 00:47:35 +07:00
|
|
|
if (ret)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
ret = i915_gem_object_set_to_gtt_domain(obj, true);
|
|
|
|
if (ret)
|
|
|
|
goto out_unpin;
|
|
|
|
|
|
|
|
ret = i915_gem_object_put_fence(obj);
|
|
|
|
if (ret)
|
|
|
|
goto out_unpin;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2013-02-22 21:12:51 +07:00
|
|
|
user_data = to_user_ptr(args->data_ptr);
|
2008-07-31 02:06:12 +07:00
|
|
|
remain = args->size;
|
|
|
|
|
2013-07-06 04:41:04 +07:00
|
|
|
offset = i915_gem_obj_ggtt_offset(obj) + args->offset;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
|
|
|
while (remain > 0) {
|
|
|
|
/* Operation in this page
|
|
|
|
*
|
2008-10-31 09:38:48 +07:00
|
|
|
* page_base = page offset within aperture
|
|
|
|
* page_offset = offset within page
|
|
|
|
* page_length = bytes to copy for this page
|
2008-07-31 02:06:12 +07:00
|
|
|
*/
|
2011-05-13 04:17:11 +07:00
|
|
|
page_base = offset & PAGE_MASK;
|
|
|
|
page_offset = offset_in_page(offset);
|
2008-10-31 09:38:48 +07:00
|
|
|
page_length = remain;
|
|
|
|
if ((page_offset + remain) > PAGE_SIZE)
|
|
|
|
page_length = PAGE_SIZE - page_offset;
|
|
|
|
|
|
|
|
/* If we get a fault while copying data, then (presumably) our
|
2009-03-09 23:42:23 +07:00
|
|
|
* source page isn't available. Return the error and we'll
|
|
|
|
* retry in the slow path.
|
2008-10-31 09:38:48 +07:00
|
|
|
*/
|
2013-01-18 03:45:15 +07:00
|
|
|
if (fast_user_write(dev_priv->gtt.mappable, page_base,
|
2012-03-26 00:47:35 +07:00
|
|
|
page_offset, user_data, page_length)) {
|
|
|
|
ret = -EFAULT;
|
|
|
|
goto out_unpin;
|
|
|
|
}
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2008-10-31 09:38:48 +07:00
|
|
|
remain -= page_length;
|
|
|
|
user_data += page_length;
|
|
|
|
offset += page_length;
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
2012-03-26 00:47:35 +07:00
|
|
|
out_unpin:
|
|
|
|
i915_gem_object_unpin(obj);
|
|
|
|
out:
|
2009-03-09 23:42:23 +07:00
|
|
|
return ret;
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
2012-03-26 00:47:40 +07:00
|
|
|
/* Per-page copy function for the shmem pwrite fastpath.
|
|
|
|
* Flushes invalid cachelines before writing to the target if
|
|
|
|
* needs_clflush_before is set and flushes out any written cachelines after
|
|
|
|
* writing if needs_clflush is set. */
|
2008-10-03 02:24:47 +07:00
|
|
|
static int
|
2012-03-26 00:47:40 +07:00
|
|
|
shmem_pwrite_fast(struct page *page, int shmem_page_offset, int page_length,
|
|
|
|
char __user *user_data,
|
|
|
|
bool page_do_bit17_swizzling,
|
|
|
|
bool needs_clflush_before,
|
|
|
|
bool needs_clflush_after)
|
2008-07-31 02:06:12 +07:00
|
|
|
{
|
2012-03-26 00:47:40 +07:00
|
|
|
char *vaddr;
|
2008-07-31 02:06:12 +07:00
|
|
|
int ret;
|
2009-03-09 23:42:23 +07:00
|
|
|
|
2012-03-26 00:47:43 +07:00
|
|
|
if (unlikely(page_do_bit17_swizzling))
|
2012-03-26 00:47:40 +07:00
|
|
|
return -EINVAL;
|
2009-03-09 23:42:23 +07:00
|
|
|
|
2012-03-26 00:47:40 +07:00
|
|
|
vaddr = kmap_atomic(page);
|
|
|
|
if (needs_clflush_before)
|
|
|
|
drm_clflush_virt_range(vaddr + shmem_page_offset,
|
|
|
|
page_length);
|
|
|
|
ret = __copy_from_user_inatomic_nocache(vaddr + shmem_page_offset,
|
|
|
|
user_data,
|
|
|
|
page_length);
|
|
|
|
if (needs_clflush_after)
|
|
|
|
drm_clflush_virt_range(vaddr + shmem_page_offset,
|
|
|
|
page_length);
|
|
|
|
kunmap_atomic(vaddr);
|
2009-03-09 23:42:23 +07:00
|
|
|
|
2012-09-05 03:02:55 +07:00
|
|
|
return ret ? -EFAULT : 0;
|
2009-03-09 23:42:23 +07:00
|
|
|
}
|
|
|
|
|
2012-03-26 00:47:40 +07:00
|
|
|
/* Only difference to the fast-path function is that this can handle bit17
|
|
|
|
* and uses non-atomic copy and kmap functions. */
|
2008-10-03 02:24:47 +07:00
|
|
|
static int
|
2012-03-26 00:47:40 +07:00
|
|
|
shmem_pwrite_slow(struct page *page, int shmem_page_offset, int page_length,
|
|
|
|
char __user *user_data,
|
|
|
|
bool page_do_bit17_swizzling,
|
|
|
|
bool needs_clflush_before,
|
|
|
|
bool needs_clflush_after)
|
2008-07-31 02:06:12 +07:00
|
|
|
{
|
2012-03-26 00:47:40 +07:00
|
|
|
char *vaddr;
|
|
|
|
int ret;
|
2010-10-28 19:45:36 +07:00
|
|
|
|
2012-03-26 00:47:40 +07:00
|
|
|
vaddr = kmap(page);
|
2012-03-26 00:47:43 +07:00
|
|
|
if (unlikely(needs_clflush_before || page_do_bit17_swizzling))
|
2012-03-26 00:47:42 +07:00
|
|
|
shmem_clflush_swizzled_range(vaddr + shmem_page_offset,
|
|
|
|
page_length,
|
|
|
|
page_do_bit17_swizzling);
|
2012-03-26 00:47:40 +07:00
|
|
|
if (page_do_bit17_swizzling)
|
|
|
|
ret = __copy_from_user_swizzled(vaddr, shmem_page_offset,
|
2010-10-28 19:45:36 +07:00
|
|
|
user_data,
|
|
|
|
page_length);
|
2012-03-26 00:47:40 +07:00
|
|
|
else
|
|
|
|
ret = __copy_from_user(vaddr + shmem_page_offset,
|
|
|
|
user_data,
|
|
|
|
page_length);
|
|
|
|
if (needs_clflush_after)
|
2012-03-26 00:47:42 +07:00
|
|
|
shmem_clflush_swizzled_range(vaddr + shmem_page_offset,
|
|
|
|
page_length,
|
|
|
|
page_do_bit17_swizzling);
|
2012-03-26 00:47:40 +07:00
|
|
|
kunmap(page);
|
2009-03-10 03:42:30 +07:00
|
|
|
|
2012-09-05 03:02:55 +07:00
|
|
|
return ret ? -EFAULT : 0;
|
2009-03-10 03:42:30 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2012-03-26 00:47:28 +07:00
|
|
|
i915_gem_shmem_pwrite(struct drm_device *dev,
|
|
|
|
struct drm_i915_gem_object *obj,
|
|
|
|
struct drm_i915_gem_pwrite *args,
|
|
|
|
struct drm_file *file)
|
2009-03-10 03:42:30 +07:00
|
|
|
{
|
|
|
|
ssize_t remain;
|
drm/i915: rewrite shmem_pwrite_slow to use copy_from_user
... instead of get_user_pages, because that fails on non page-backed
user addresses like e.g. a gtt mapping of a bo.
To get there essentially copy the vfs read path into pagecache. We
can't call that right away because we have to take care of bit17
swizzling. To not deadlock with our own pagefault handler we need
to completely drop struct_mutex, reducing the atomicty-guarantees
of our userspace abi. Implications for racing with other gem ioctl:
- execbuf, pwrite, pread: Due to -EFAULT fallback to slow paths there's
already the risk of the pwrite call not being atomic, no degration.
- read/write access to mmaps: already fully racy, no degration.
- set_tiling: Calling set_tiling while reading/writing is already
pretty much undefined, now it just got a bit worse. set_tiling is
only called by libdrm on unused/new bos, so no problem.
- set_domain: When changing to the gtt domain while copying (without any
read/write access, e.g. for synchronization), we might leave unflushed
data in the cpu caches. The clflush_object at the end of pwrite_slow
takes care of this problem.
- truncating of purgeable objects: the shmem_read_mapping_page call could
reinstate backing storage for truncated objects. The check at the end
of pwrite_slow takes care of this.
v2:
- add missing intel_gtt_chipset_flush
- add __ to copy_from_user_swizzled as suggest by Chris Wilson.
v3: Fixup bit17 swizzling, it swizzled the wrong pages.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2011-12-14 19:57:31 +07:00
|
|
|
loff_t offset;
|
|
|
|
char __user *user_data;
|
2012-02-15 20:42:43 +07:00
|
|
|
int shmem_page_offset, page_length, ret = 0;
|
drm/i915: rewrite shmem_pwrite_slow to use copy_from_user
... instead of get_user_pages, because that fails on non page-backed
user addresses like e.g. a gtt mapping of a bo.
To get there essentially copy the vfs read path into pagecache. We
can't call that right away because we have to take care of bit17
swizzling. To not deadlock with our own pagefault handler we need
to completely drop struct_mutex, reducing the atomicty-guarantees
of our userspace abi. Implications for racing with other gem ioctl:
- execbuf, pwrite, pread: Due to -EFAULT fallback to slow paths there's
already the risk of the pwrite call not being atomic, no degration.
- read/write access to mmaps: already fully racy, no degration.
- set_tiling: Calling set_tiling while reading/writing is already
pretty much undefined, now it just got a bit worse. set_tiling is
only called by libdrm on unused/new bos, so no problem.
- set_domain: When changing to the gtt domain while copying (without any
read/write access, e.g. for synchronization), we might leave unflushed
data in the cpu caches. The clflush_object at the end of pwrite_slow
takes care of this problem.
- truncating of purgeable objects: the shmem_read_mapping_page call could
reinstate backing storage for truncated objects. The check at the end
of pwrite_slow takes care of this.
v2:
- add missing intel_gtt_chipset_flush
- add __ to copy_from_user_swizzled as suggest by Chris Wilson.
v3: Fixup bit17 swizzling, it swizzled the wrong pages.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2011-12-14 19:57:31 +07:00
|
|
|
int obj_do_bit17_swizzling, page_do_bit17_swizzling;
|
2012-03-26 00:47:28 +07:00
|
|
|
int hit_slowpath = 0;
|
2012-03-26 00:47:37 +07:00
|
|
|
int needs_clflush_after = 0;
|
|
|
|
int needs_clflush_before = 0;
|
2013-02-19 00:28:02 +07:00
|
|
|
struct sg_page_iter sg_iter;
|
2009-03-10 03:42:30 +07:00
|
|
|
|
2013-02-22 21:12:51 +07:00
|
|
|
user_data = to_user_ptr(args->data_ptr);
|
2009-03-10 03:42:30 +07:00
|
|
|
remain = args->size;
|
|
|
|
|
drm/i915: rewrite shmem_pwrite_slow to use copy_from_user
... instead of get_user_pages, because that fails on non page-backed
user addresses like e.g. a gtt mapping of a bo.
To get there essentially copy the vfs read path into pagecache. We
can't call that right away because we have to take care of bit17
swizzling. To not deadlock with our own pagefault handler we need
to completely drop struct_mutex, reducing the atomicty-guarantees
of our userspace abi. Implications for racing with other gem ioctl:
- execbuf, pwrite, pread: Due to -EFAULT fallback to slow paths there's
already the risk of the pwrite call not being atomic, no degration.
- read/write access to mmaps: already fully racy, no degration.
- set_tiling: Calling set_tiling while reading/writing is already
pretty much undefined, now it just got a bit worse. set_tiling is
only called by libdrm on unused/new bos, so no problem.
- set_domain: When changing to the gtt domain while copying (without any
read/write access, e.g. for synchronization), we might leave unflushed
data in the cpu caches. The clflush_object at the end of pwrite_slow
takes care of this problem.
- truncating of purgeable objects: the shmem_read_mapping_page call could
reinstate backing storage for truncated objects. The check at the end
of pwrite_slow takes care of this.
v2:
- add missing intel_gtt_chipset_flush
- add __ to copy_from_user_swizzled as suggest by Chris Wilson.
v3: Fixup bit17 swizzling, it swizzled the wrong pages.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2011-12-14 19:57:31 +07:00
|
|
|
obj_do_bit17_swizzling = i915_gem_object_needs_bit17_swizzle(obj);
|
2009-03-10 03:42:30 +07:00
|
|
|
|
2012-03-26 00:47:37 +07:00
|
|
|
if (obj->base.write_domain != I915_GEM_DOMAIN_CPU) {
|
|
|
|
/* If we're not in the cpu write domain, set ourself into the gtt
|
|
|
|
* write domain and manually flush cachelines (if required). This
|
|
|
|
* optimizes for the case when the gpu will use the data
|
|
|
|
* right away and we therefore have to clflush anyway. */
|
2013-08-09 18:26:45 +07:00
|
|
|
needs_clflush_after = cpu_write_needs_clflush(obj);
|
2013-09-12 04:57:48 +07:00
|
|
|
ret = i915_gem_object_wait_rendering(obj, false);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2012-03-26 00:47:37 +07:00
|
|
|
}
|
2013-08-08 20:41:03 +07:00
|
|
|
/* Same trick applies to invalidate partially written cachelines read
|
|
|
|
* before writing. */
|
|
|
|
if ((obj->base.read_domains & I915_GEM_DOMAIN_CPU) == 0)
|
|
|
|
needs_clflush_before =
|
|
|
|
!cpu_cache_is_coherent(dev, obj->cache_level);
|
2012-03-26 00:47:37 +07:00
|
|
|
|
2012-09-05 03:02:55 +07:00
|
|
|
ret = i915_gem_object_get_pages(obj);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
i915_gem_object_pin_pages(obj);
|
|
|
|
|
2008-07-31 02:06:12 +07:00
|
|
|
offset = args->offset;
|
2010-11-09 02:18:58 +07:00
|
|
|
obj->dirty = 1;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2013-02-19 00:28:02 +07:00
|
|
|
for_each_sg_page(obj->pages->sgl, &sg_iter, obj->pages->nents,
|
|
|
|
offset >> PAGE_SHIFT) {
|
2013-03-26 20:14:18 +07:00
|
|
|
struct page *page = sg_page_iter_page(&sg_iter);
|
2012-03-26 00:47:37 +07:00
|
|
|
int partial_cacheline_write;
|
2010-10-28 19:45:36 +07:00
|
|
|
|
2012-06-01 21:20:22 +07:00
|
|
|
if (remain <= 0)
|
|
|
|
break;
|
|
|
|
|
2009-03-10 03:42:30 +07:00
|
|
|
/* Operation in this page
|
|
|
|
*
|
|
|
|
* shmem_page_offset = offset within page in shmem file
|
|
|
|
* page_length = bytes to copy for this page
|
|
|
|
*/
|
2011-05-13 04:17:11 +07:00
|
|
|
shmem_page_offset = offset_in_page(offset);
|
2009-03-10 03:42:30 +07:00
|
|
|
|
|
|
|
page_length = remain;
|
|
|
|
if ((shmem_page_offset + page_length) > PAGE_SIZE)
|
|
|
|
page_length = PAGE_SIZE - shmem_page_offset;
|
|
|
|
|
2012-03-26 00:47:37 +07:00
|
|
|
/* If we don't overwrite a cacheline completely we need to be
|
|
|
|
* careful to have up-to-date data by first clflushing. Don't
|
|
|
|
* overcomplicate things and flush the entire patch. */
|
|
|
|
partial_cacheline_write = needs_clflush_before &&
|
|
|
|
((shmem_page_offset | page_length)
|
|
|
|
& (boot_cpu_data.x86_clflush_size - 1));
|
|
|
|
|
drm/i915: rewrite shmem_pwrite_slow to use copy_from_user
... instead of get_user_pages, because that fails on non page-backed
user addresses like e.g. a gtt mapping of a bo.
To get there essentially copy the vfs read path into pagecache. We
can't call that right away because we have to take care of bit17
swizzling. To not deadlock with our own pagefault handler we need
to completely drop struct_mutex, reducing the atomicty-guarantees
of our userspace abi. Implications for racing with other gem ioctl:
- execbuf, pwrite, pread: Due to -EFAULT fallback to slow paths there's
already the risk of the pwrite call not being atomic, no degration.
- read/write access to mmaps: already fully racy, no degration.
- set_tiling: Calling set_tiling while reading/writing is already
pretty much undefined, now it just got a bit worse. set_tiling is
only called by libdrm on unused/new bos, so no problem.
- set_domain: When changing to the gtt domain while copying (without any
read/write access, e.g. for synchronization), we might leave unflushed
data in the cpu caches. The clflush_object at the end of pwrite_slow
takes care of this problem.
- truncating of purgeable objects: the shmem_read_mapping_page call could
reinstate backing storage for truncated objects. The check at the end
of pwrite_slow takes care of this.
v2:
- add missing intel_gtt_chipset_flush
- add __ to copy_from_user_swizzled as suggest by Chris Wilson.
v3: Fixup bit17 swizzling, it swizzled the wrong pages.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2011-12-14 19:57:31 +07:00
|
|
|
page_do_bit17_swizzling = obj_do_bit17_swizzling &&
|
|
|
|
(page_to_phys(page) & (1 << 17)) != 0;
|
|
|
|
|
2012-03-26 00:47:40 +07:00
|
|
|
ret = shmem_pwrite_fast(page, shmem_page_offset, page_length,
|
|
|
|
user_data, page_do_bit17_swizzling,
|
|
|
|
partial_cacheline_write,
|
|
|
|
needs_clflush_after);
|
|
|
|
if (ret == 0)
|
|
|
|
goto next_page;
|
2012-03-26 00:47:28 +07:00
|
|
|
|
|
|
|
hit_slowpath = 1;
|
|
|
|
mutex_unlock(&dev->struct_mutex);
|
2012-03-26 00:47:40 +07:00
|
|
|
ret = shmem_pwrite_slow(page, shmem_page_offset, page_length,
|
|
|
|
user_data, page_do_bit17_swizzling,
|
|
|
|
partial_cacheline_write,
|
|
|
|
needs_clflush_after);
|
2009-03-10 03:42:30 +07:00
|
|
|
|
2012-03-26 00:47:28 +07:00
|
|
|
mutex_lock(&dev->struct_mutex);
|
2012-09-05 03:02:55 +07:00
|
|
|
|
2012-03-26 00:47:28 +07:00
|
|
|
next_page:
|
2010-10-28 19:45:36 +07:00
|
|
|
set_page_dirty(page);
|
|
|
|
mark_page_accessed(page);
|
|
|
|
|
2012-09-05 03:02:55 +07:00
|
|
|
if (ret)
|
drm/i915: rewrite shmem_pwrite_slow to use copy_from_user
... instead of get_user_pages, because that fails on non page-backed
user addresses like e.g. a gtt mapping of a bo.
To get there essentially copy the vfs read path into pagecache. We
can't call that right away because we have to take care of bit17
swizzling. To not deadlock with our own pagefault handler we need
to completely drop struct_mutex, reducing the atomicty-guarantees
of our userspace abi. Implications for racing with other gem ioctl:
- execbuf, pwrite, pread: Due to -EFAULT fallback to slow paths there's
already the risk of the pwrite call not being atomic, no degration.
- read/write access to mmaps: already fully racy, no degration.
- set_tiling: Calling set_tiling while reading/writing is already
pretty much undefined, now it just got a bit worse. set_tiling is
only called by libdrm on unused/new bos, so no problem.
- set_domain: When changing to the gtt domain while copying (without any
read/write access, e.g. for synchronization), we might leave unflushed
data in the cpu caches. The clflush_object at the end of pwrite_slow
takes care of this problem.
- truncating of purgeable objects: the shmem_read_mapping_page call could
reinstate backing storage for truncated objects. The check at the end
of pwrite_slow takes care of this.
v2:
- add missing intel_gtt_chipset_flush
- add __ to copy_from_user_swizzled as suggest by Chris Wilson.
v3: Fixup bit17 swizzling, it swizzled the wrong pages.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2011-12-14 19:57:31 +07:00
|
|
|
goto out;
|
|
|
|
|
2009-03-10 03:42:30 +07:00
|
|
|
remain -= page_length;
|
drm/i915: rewrite shmem_pwrite_slow to use copy_from_user
... instead of get_user_pages, because that fails on non page-backed
user addresses like e.g. a gtt mapping of a bo.
To get there essentially copy the vfs read path into pagecache. We
can't call that right away because we have to take care of bit17
swizzling. To not deadlock with our own pagefault handler we need
to completely drop struct_mutex, reducing the atomicty-guarantees
of our userspace abi. Implications for racing with other gem ioctl:
- execbuf, pwrite, pread: Due to -EFAULT fallback to slow paths there's
already the risk of the pwrite call not being atomic, no degration.
- read/write access to mmaps: already fully racy, no degration.
- set_tiling: Calling set_tiling while reading/writing is already
pretty much undefined, now it just got a bit worse. set_tiling is
only called by libdrm on unused/new bos, so no problem.
- set_domain: When changing to the gtt domain while copying (without any
read/write access, e.g. for synchronization), we might leave unflushed
data in the cpu caches. The clflush_object at the end of pwrite_slow
takes care of this problem.
- truncating of purgeable objects: the shmem_read_mapping_page call could
reinstate backing storage for truncated objects. The check at the end
of pwrite_slow takes care of this.
v2:
- add missing intel_gtt_chipset_flush
- add __ to copy_from_user_swizzled as suggest by Chris Wilson.
v3: Fixup bit17 swizzling, it swizzled the wrong pages.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2011-12-14 19:57:31 +07:00
|
|
|
user_data += page_length;
|
2009-03-10 03:42:30 +07:00
|
|
|
offset += page_length;
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
2010-10-14 21:03:58 +07:00
|
|
|
out:
|
2012-09-05 03:02:55 +07:00
|
|
|
i915_gem_object_unpin_pages(obj);
|
|
|
|
|
2012-03-26 00:47:28 +07:00
|
|
|
if (hit_slowpath) {
|
2012-11-15 22:53:58 +07:00
|
|
|
/*
|
|
|
|
* Fixup: Flush cpu caches in case we didn't flush the dirty
|
|
|
|
* cachelines in-line while writing and the object moved
|
|
|
|
* out of the cpu write domain while we've dropped the lock.
|
|
|
|
*/
|
|
|
|
if (!needs_clflush_after &&
|
|
|
|
obj->base.write_domain != I915_GEM_DOMAIN_CPU) {
|
2013-08-08 20:41:09 +07:00
|
|
|
if (i915_gem_clflush_object(obj, obj->pin_display))
|
|
|
|
i915_gem_chipset_flush(dev);
|
2012-03-26 00:47:28 +07:00
|
|
|
}
|
drm/i915: rewrite shmem_pwrite_slow to use copy_from_user
... instead of get_user_pages, because that fails on non page-backed
user addresses like e.g. a gtt mapping of a bo.
To get there essentially copy the vfs read path into pagecache. We
can't call that right away because we have to take care of bit17
swizzling. To not deadlock with our own pagefault handler we need
to completely drop struct_mutex, reducing the atomicty-guarantees
of our userspace abi. Implications for racing with other gem ioctl:
- execbuf, pwrite, pread: Due to -EFAULT fallback to slow paths there's
already the risk of the pwrite call not being atomic, no degration.
- read/write access to mmaps: already fully racy, no degration.
- set_tiling: Calling set_tiling while reading/writing is already
pretty much undefined, now it just got a bit worse. set_tiling is
only called by libdrm on unused/new bos, so no problem.
- set_domain: When changing to the gtt domain while copying (without any
read/write access, e.g. for synchronization), we might leave unflushed
data in the cpu caches. The clflush_object at the end of pwrite_slow
takes care of this problem.
- truncating of purgeable objects: the shmem_read_mapping_page call could
reinstate backing storage for truncated objects. The check at the end
of pwrite_slow takes care of this.
v2:
- add missing intel_gtt_chipset_flush
- add __ to copy_from_user_swizzled as suggest by Chris Wilson.
v3: Fixup bit17 swizzling, it swizzled the wrong pages.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2011-12-14 19:57:31 +07:00
|
|
|
}
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2012-03-26 00:47:37 +07:00
|
|
|
if (needs_clflush_after)
|
2012-11-05 00:21:27 +07:00
|
|
|
i915_gem_chipset_flush(dev);
|
2012-03-26 00:47:37 +07:00
|
|
|
|
2009-03-10 03:42:30 +07:00
|
|
|
return ret;
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Writes data to the object referenced by handle.
|
|
|
|
*
|
|
|
|
* On error, the contents of the buffer that were to be modified are undefined.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
|
2010-10-14 21:03:58 +07:00
|
|
|
struct drm_file *file)
|
2008-07-31 02:06:12 +07:00
|
|
|
{
|
|
|
|
struct drm_i915_gem_pwrite *args = data;
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_i915_gem_object *obj;
|
2010-11-17 16:10:42 +07:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (args->size == 0)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (!access_ok(VERIFY_READ,
|
2013-02-22 21:12:51 +07:00
|
|
|
to_user_ptr(args->data_ptr),
|
2010-11-17 16:10:42 +07:00
|
|
|
args->size))
|
|
|
|
return -EFAULT;
|
|
|
|
|
2013-07-19 12:51:24 +07:00
|
|
|
if (likely(!i915_prefault_disable)) {
|
|
|
|
ret = fault_in_multipages_readable(to_user_ptr(args->data_ptr),
|
|
|
|
args->size);
|
|
|
|
if (ret)
|
|
|
|
return -EFAULT;
|
|
|
|
}
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2010-10-14 21:03:58 +07:00
|
|
|
ret = i915_mutex_lock_interruptible(dev);
|
2010-10-17 15:45:41 +07:00
|
|
|
if (ret)
|
2010-10-14 21:03:58 +07:00
|
|
|
return ret;
|
2010-10-17 15:45:41 +07:00
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
obj = to_intel_bo(drm_gem_object_lookup(dev, file, args->handle));
|
2011-02-19 18:31:06 +07:00
|
|
|
if (&obj->base == NULL) {
|
2010-10-17 15:45:41 +07:00
|
|
|
ret = -ENOENT;
|
|
|
|
goto unlock;
|
2010-10-14 21:03:58 +07:00
|
|
|
}
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2010-09-27 02:21:44 +07:00
|
|
|
/* Bounds check destination. */
|
2010-11-09 02:18:58 +07:00
|
|
|
if (args->offset > obj->base.size ||
|
|
|
|
args->size > obj->base.size - args->offset) {
|
2010-09-27 02:50:05 +07:00
|
|
|
ret = -EINVAL;
|
2010-09-27 02:23:38 +07:00
|
|
|
goto out;
|
2010-09-27 02:50:05 +07:00
|
|
|
}
|
|
|
|
|
2012-05-10 20:25:09 +07:00
|
|
|
/* prime objects have no backing filp to GEM pread/pwrite
|
|
|
|
* pages from.
|
|
|
|
*/
|
|
|
|
if (!obj->base.filp) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2011-02-03 18:57:46 +07:00
|
|
|
trace_i915_gem_object_pwrite(obj, args->offset, args->size);
|
|
|
|
|
2012-03-26 00:47:35 +07:00
|
|
|
ret = -EFAULT;
|
2008-07-31 02:06:12 +07:00
|
|
|
/* We can only do the GTT pwrite on untiled buffers, as otherwise
|
|
|
|
* it would end up going through the fenced access, and we'll get
|
|
|
|
* different detiling behavior between reading and writing.
|
|
|
|
* pread/pwrite currently are reading and writing from the CPU
|
|
|
|
* perspective, requiring manual detiling by the client.
|
|
|
|
*/
|
2011-12-14 19:57:30 +07:00
|
|
|
if (obj->phys_obj) {
|
2010-10-14 21:03:58 +07:00
|
|
|
ret = i915_gem_phys_pwrite(dev, obj, args, file);
|
2011-12-14 19:57:30 +07:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2013-08-09 18:26:45 +07:00
|
|
|
if (obj->tiling_mode == I915_TILING_NONE &&
|
|
|
|
obj->base.write_domain != I915_GEM_DOMAIN_CPU &&
|
|
|
|
cpu_write_needs_clflush(obj)) {
|
2010-10-14 21:03:58 +07:00
|
|
|
ret = i915_gem_gtt_pwrite_fast(dev, obj, args, file);
|
2012-03-26 00:47:35 +07:00
|
|
|
/* Note that the gtt paths might fail with non-page-backed user
|
|
|
|
* pointers (e.g. gtt mappings when moving data between
|
|
|
|
* textures). Fallback to the shmem path in that case. */
|
2010-10-14 21:03:58 +07:00
|
|
|
}
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2012-08-11 21:41:04 +07:00
|
|
|
if (ret == -EFAULT || ret == -ENOSPC)
|
2012-03-26 00:47:35 +07:00
|
|
|
ret = i915_gem_shmem_pwrite(dev, obj, args, file);
|
2011-12-14 19:57:30 +07:00
|
|
|
|
2010-09-27 02:23:38 +07:00
|
|
|
out:
|
2010-11-09 02:18:58 +07:00
|
|
|
drm_gem_object_unreference(&obj->base);
|
2010-10-17 15:45:41 +07:00
|
|
|
unlock:
|
2010-10-14 21:03:58 +07:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
2008-07-31 02:06:12 +07:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-08-24 15:35:08 +07:00
|
|
|
int
|
2012-11-14 23:14:05 +07:00
|
|
|
i915_gem_check_wedge(struct i915_gpu_error *error,
|
2012-08-24 15:35:08 +07:00
|
|
|
bool interruptible)
|
|
|
|
{
|
2012-11-15 23:17:22 +07:00
|
|
|
if (i915_reset_in_progress(error)) {
|
2012-08-24 15:35:08 +07:00
|
|
|
/* Non-interruptible callers can't handle -EAGAIN, hence return
|
|
|
|
* -EIO unconditionally for these. */
|
|
|
|
if (!interruptible)
|
|
|
|
return -EIO;
|
|
|
|
|
2012-11-15 23:17:22 +07:00
|
|
|
/* Recovery complete, but the reset failed ... */
|
|
|
|
if (i915_terminally_wedged(error))
|
2012-08-24 15:35:08 +07:00
|
|
|
return -EIO;
|
|
|
|
|
|
|
|
return -EAGAIN;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Compare seqno against outstanding lazy request. Emit a request if they are
|
|
|
|
* equal.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
i915_gem_check_olr(struct intel_ring_buffer *ring, u32 seqno)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
BUG_ON(!mutex_is_locked(&ring->dev->struct_mutex));
|
|
|
|
|
|
|
|
ret = 0;
|
2013-09-04 16:45:51 +07:00
|
|
|
if (seqno == ring->outstanding_lazy_seqno)
|
2013-06-12 16:35:30 +07:00
|
|
|
ret = i915_add_request(ring, NULL);
|
2012-08-24 15:35:08 +07:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2013-09-25 23:34:55 +07:00
|
|
|
static void fake_irq(unsigned long data)
|
|
|
|
{
|
|
|
|
wake_up_process((struct task_struct *)data);
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool missed_irq(struct drm_i915_private *dev_priv,
|
|
|
|
struct intel_ring_buffer *ring)
|
|
|
|
{
|
|
|
|
return test_bit(ring->id, &dev_priv->gpu_error.missed_irq_rings);
|
|
|
|
}
|
|
|
|
|
drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-25 23:34:56 +07:00
|
|
|
static bool can_wait_boost(struct drm_i915_file_private *file_priv)
|
|
|
|
{
|
|
|
|
if (file_priv == NULL)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return !atomic_xchg(&file_priv->rps_wait_boost, true);
|
|
|
|
}
|
|
|
|
|
2012-08-24 15:35:08 +07:00
|
|
|
/**
|
|
|
|
* __wait_seqno - wait until execution of seqno has finished
|
|
|
|
* @ring: the ring expected to report seqno
|
|
|
|
* @seqno: duh!
|
drm/i915: create a race-free reset detection
With the previous patch the state transition handling of the reset
code itself is now (hopefully) race free and solid. But that still
leaves out everyone else - with the various lock-free wait paths
we have there's the possibility that the reset happens between the
point where we read the seqno we should wait on and the actual wait.
And if __wait_seqno then never sees the RESET_IN_PROGRESS state, we'll
happily wait for a seqno which will in all likelyhood never signal.
In practice this is not a big problem since the X server gets
constantly interrupted, and can then submit more work (hopefully) to
unblock everyone else: As soon as a new seqno write lands, all waiters
will unblock. But running the i-g-t reset testcase ZZ_hangman can
expose this race, especially on slower hw with fewer cpu cores.
Now looking forward to ARB_robustness and friends that's not the best
possible behaviour, hence this patch adds a reset_counter to be able
to detect any reset, even if a given thread never observed the
in-progress state.
The important part is to correctly order things:
- The write side needs to increment the counter after any seqno gets
reset. Hence we need to do that at the end of the reset work, and
again wake everyone up. We also need to place a barrier in between
any possible seqno changes and the counter increment, since any
unlock operations only guarantee that nothing leaks out, but not
that at later load operation gets moved ahead.
- On the read side we need to ensure that no reset can sneak in and
invalidate the seqno. In all cases we can use the one-sided barrier
that unlock operations guarantee (of the lock protecting the
respective seqno/ring pair) to ensure correct ordering. Hence it is
sufficient to place the atomic read before the mutex/spin_unlock and
no additional barriers are required.
The end-result of all this is that we need to wake up everyone twice
in a reset operation:
- First, before the reset starts, to get any lockholders of the locks,
so that the reset can proceed.
- Second, after the reset is completed, to allow waiters to properly
and reliably detect the reset condition and bail out.
I admit that this entire reset_counter thing smells a bit like
overkill, but I think it's justified since it makes it really explicit
what the bail-out condition is. And we need a reset counter anyway to
implement ARB_robustness, and imo with finer-grained locking on the
horizont this is the most resilient scheme I could think of.
v2: Drop spurious change in the wait_for_error EXIT_COND - we only
need to wait until we leave the reset-in-progress wedged state.
v3: Don't play tricks with barriers in the throttle ioctl, the
spin_unlock is barrier enough.
I've also considered using a little helper to grab the current
reset_counter, but then decided that hiding the atomic_read isn't a
great idea, since having it explicitly show up in the code is a nice
remainder to reviews to check the memory barriers.
v4: Add a comment to explain why we need to fall through in
__wait_seqno in the end variable assignments.
v5: Review from Damien:
- s/smb/smp/ in a comment
- don't increment the reset counter after we've set it to WEDGED. Now
we (again) properly wedge the gpu when the reset fails.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-06 15:01:42 +07:00
|
|
|
* @reset_counter: reset sequence associated with the given seqno
|
2012-08-24 15:35:08 +07:00
|
|
|
* @interruptible: do an interruptible wait (normally yes)
|
|
|
|
* @timeout: in - how long to wait (NULL forever); out - how much time remaining
|
|
|
|
*
|
drm/i915: create a race-free reset detection
With the previous patch the state transition handling of the reset
code itself is now (hopefully) race free and solid. But that still
leaves out everyone else - with the various lock-free wait paths
we have there's the possibility that the reset happens between the
point where we read the seqno we should wait on and the actual wait.
And if __wait_seqno then never sees the RESET_IN_PROGRESS state, we'll
happily wait for a seqno which will in all likelyhood never signal.
In practice this is not a big problem since the X server gets
constantly interrupted, and can then submit more work (hopefully) to
unblock everyone else: As soon as a new seqno write lands, all waiters
will unblock. But running the i-g-t reset testcase ZZ_hangman can
expose this race, especially on slower hw with fewer cpu cores.
Now looking forward to ARB_robustness and friends that's not the best
possible behaviour, hence this patch adds a reset_counter to be able
to detect any reset, even if a given thread never observed the
in-progress state.
The important part is to correctly order things:
- The write side needs to increment the counter after any seqno gets
reset. Hence we need to do that at the end of the reset work, and
again wake everyone up. We also need to place a barrier in between
any possible seqno changes and the counter increment, since any
unlock operations only guarantee that nothing leaks out, but not
that at later load operation gets moved ahead.
- On the read side we need to ensure that no reset can sneak in and
invalidate the seqno. In all cases we can use the one-sided barrier
that unlock operations guarantee (of the lock protecting the
respective seqno/ring pair) to ensure correct ordering. Hence it is
sufficient to place the atomic read before the mutex/spin_unlock and
no additional barriers are required.
The end-result of all this is that we need to wake up everyone twice
in a reset operation:
- First, before the reset starts, to get any lockholders of the locks,
so that the reset can proceed.
- Second, after the reset is completed, to allow waiters to properly
and reliably detect the reset condition and bail out.
I admit that this entire reset_counter thing smells a bit like
overkill, but I think it's justified since it makes it really explicit
what the bail-out condition is. And we need a reset counter anyway to
implement ARB_robustness, and imo with finer-grained locking on the
horizont this is the most resilient scheme I could think of.
v2: Drop spurious change in the wait_for_error EXIT_COND - we only
need to wait until we leave the reset-in-progress wedged state.
v3: Don't play tricks with barriers in the throttle ioctl, the
spin_unlock is barrier enough.
I've also considered using a little helper to grab the current
reset_counter, but then decided that hiding the atomic_read isn't a
great idea, since having it explicitly show up in the code is a nice
remainder to reviews to check the memory barriers.
v4: Add a comment to explain why we need to fall through in
__wait_seqno in the end variable assignments.
v5: Review from Damien:
- s/smb/smp/ in a comment
- don't increment the reset counter after we've set it to WEDGED. Now
we (again) properly wedge the gpu when the reset fails.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-06 15:01:42 +07:00
|
|
|
* Note: It is of utmost importance that the passed in seqno and reset_counter
|
|
|
|
* values have been read by the caller in an smp safe manner. Where read-side
|
|
|
|
* locks are involved, it is sufficient to read the reset_counter before
|
|
|
|
* unlocking the lock that protects the seqno. For lockless tricks, the
|
|
|
|
* reset_counter _must_ be read before, and an appropriate smp_rmb must be
|
|
|
|
* inserted.
|
|
|
|
*
|
2012-08-24 15:35:08 +07:00
|
|
|
* Returns 0 if the seqno was found within the alloted time. Else returns the
|
|
|
|
* errno with remaining time filled in timeout argument.
|
|
|
|
*/
|
|
|
|
static int __wait_seqno(struct intel_ring_buffer *ring, u32 seqno,
|
drm/i915: create a race-free reset detection
With the previous patch the state transition handling of the reset
code itself is now (hopefully) race free and solid. But that still
leaves out everyone else - with the various lock-free wait paths
we have there's the possibility that the reset happens between the
point where we read the seqno we should wait on and the actual wait.
And if __wait_seqno then never sees the RESET_IN_PROGRESS state, we'll
happily wait for a seqno which will in all likelyhood never signal.
In practice this is not a big problem since the X server gets
constantly interrupted, and can then submit more work (hopefully) to
unblock everyone else: As soon as a new seqno write lands, all waiters
will unblock. But running the i-g-t reset testcase ZZ_hangman can
expose this race, especially on slower hw with fewer cpu cores.
Now looking forward to ARB_robustness and friends that's not the best
possible behaviour, hence this patch adds a reset_counter to be able
to detect any reset, even if a given thread never observed the
in-progress state.
The important part is to correctly order things:
- The write side needs to increment the counter after any seqno gets
reset. Hence we need to do that at the end of the reset work, and
again wake everyone up. We also need to place a barrier in between
any possible seqno changes and the counter increment, since any
unlock operations only guarantee that nothing leaks out, but not
that at later load operation gets moved ahead.
- On the read side we need to ensure that no reset can sneak in and
invalidate the seqno. In all cases we can use the one-sided barrier
that unlock operations guarantee (of the lock protecting the
respective seqno/ring pair) to ensure correct ordering. Hence it is
sufficient to place the atomic read before the mutex/spin_unlock and
no additional barriers are required.
The end-result of all this is that we need to wake up everyone twice
in a reset operation:
- First, before the reset starts, to get any lockholders of the locks,
so that the reset can proceed.
- Second, after the reset is completed, to allow waiters to properly
and reliably detect the reset condition and bail out.
I admit that this entire reset_counter thing smells a bit like
overkill, but I think it's justified since it makes it really explicit
what the bail-out condition is. And we need a reset counter anyway to
implement ARB_robustness, and imo with finer-grained locking on the
horizont this is the most resilient scheme I could think of.
v2: Drop spurious change in the wait_for_error EXIT_COND - we only
need to wait until we leave the reset-in-progress wedged state.
v3: Don't play tricks with barriers in the throttle ioctl, the
spin_unlock is barrier enough.
I've also considered using a little helper to grab the current
reset_counter, but then decided that hiding the atomic_read isn't a
great idea, since having it explicitly show up in the code is a nice
remainder to reviews to check the memory barriers.
v4: Add a comment to explain why we need to fall through in
__wait_seqno in the end variable assignments.
v5: Review from Damien:
- s/smb/smp/ in a comment
- don't increment the reset counter after we've set it to WEDGED. Now
we (again) properly wedge the gpu when the reset fails.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-06 15:01:42 +07:00
|
|
|
unsigned reset_counter,
|
drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-25 23:34:56 +07:00
|
|
|
bool interruptible,
|
|
|
|
struct timespec *timeout,
|
|
|
|
struct drm_i915_file_private *file_priv)
|
2012-08-24 15:35:08 +07:00
|
|
|
{
|
|
|
|
drm_i915_private_t *dev_priv = ring->dev->dev_private;
|
2013-09-25 23:34:55 +07:00
|
|
|
struct timespec before, now;
|
|
|
|
DEFINE_WAIT(wait);
|
2013-12-10 22:02:43 +07:00
|
|
|
unsigned long timeout_expire;
|
2012-08-24 15:35:08 +07:00
|
|
|
int ret;
|
|
|
|
|
2013-08-19 23:18:09 +07:00
|
|
|
WARN(dev_priv->pc8.irqs_disabled, "IRQs disabled\n");
|
|
|
|
|
2012-08-24 15:35:08 +07:00
|
|
|
if (i915_seqno_passed(ring->get_seqno(ring, true), seqno))
|
|
|
|
return 0;
|
|
|
|
|
2013-12-10 22:02:43 +07:00
|
|
|
timeout_expire = timeout ? jiffies + timespec_to_jiffies_timeout(timeout) : 0;
|
2012-08-24 15:35:08 +07:00
|
|
|
|
drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-25 23:34:56 +07:00
|
|
|
if (dev_priv->info->gen >= 6 && can_wait_boost(file_priv)) {
|
|
|
|
gen6_rps_boost(dev_priv);
|
|
|
|
if (file_priv)
|
|
|
|
mod_delayed_work(dev_priv->wq,
|
|
|
|
&file_priv->mm.idle_work,
|
|
|
|
msecs_to_jiffies(100));
|
|
|
|
}
|
|
|
|
|
2013-09-25 23:34:55 +07:00
|
|
|
if (!(dev_priv->gpu_error.test_irq_rings & intel_ring_flag(ring)) &&
|
|
|
|
WARN_ON(!ring->irq_get(ring)))
|
2012-08-24 15:35:08 +07:00
|
|
|
return -ENODEV;
|
|
|
|
|
2013-09-25 23:34:55 +07:00
|
|
|
/* Record current time in case interrupted by signal, or wedged */
|
|
|
|
trace_i915_gem_request_wait_begin(ring, seqno);
|
2012-08-24 15:35:08 +07:00
|
|
|
getrawmonotonic(&before);
|
2013-09-25 23:34:55 +07:00
|
|
|
for (;;) {
|
|
|
|
struct timer_list timer;
|
2012-08-24 15:35:08 +07:00
|
|
|
|
2013-09-25 23:34:55 +07:00
|
|
|
prepare_to_wait(&ring->irq_queue, &wait,
|
|
|
|
interruptible ? TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE);
|
2012-08-24 15:35:08 +07:00
|
|
|
|
drm/i915: create a race-free reset detection
With the previous patch the state transition handling of the reset
code itself is now (hopefully) race free and solid. But that still
leaves out everyone else - with the various lock-free wait paths
we have there's the possibility that the reset happens between the
point where we read the seqno we should wait on and the actual wait.
And if __wait_seqno then never sees the RESET_IN_PROGRESS state, we'll
happily wait for a seqno which will in all likelyhood never signal.
In practice this is not a big problem since the X server gets
constantly interrupted, and can then submit more work (hopefully) to
unblock everyone else: As soon as a new seqno write lands, all waiters
will unblock. But running the i-g-t reset testcase ZZ_hangman can
expose this race, especially on slower hw with fewer cpu cores.
Now looking forward to ARB_robustness and friends that's not the best
possible behaviour, hence this patch adds a reset_counter to be able
to detect any reset, even if a given thread never observed the
in-progress state.
The important part is to correctly order things:
- The write side needs to increment the counter after any seqno gets
reset. Hence we need to do that at the end of the reset work, and
again wake everyone up. We also need to place a barrier in between
any possible seqno changes and the counter increment, since any
unlock operations only guarantee that nothing leaks out, but not
that at later load operation gets moved ahead.
- On the read side we need to ensure that no reset can sneak in and
invalidate the seqno. In all cases we can use the one-sided barrier
that unlock operations guarantee (of the lock protecting the
respective seqno/ring pair) to ensure correct ordering. Hence it is
sufficient to place the atomic read before the mutex/spin_unlock and
no additional barriers are required.
The end-result of all this is that we need to wake up everyone twice
in a reset operation:
- First, before the reset starts, to get any lockholders of the locks,
so that the reset can proceed.
- Second, after the reset is completed, to allow waiters to properly
and reliably detect the reset condition and bail out.
I admit that this entire reset_counter thing smells a bit like
overkill, but I think it's justified since it makes it really explicit
what the bail-out condition is. And we need a reset counter anyway to
implement ARB_robustness, and imo with finer-grained locking on the
horizont this is the most resilient scheme I could think of.
v2: Drop spurious change in the wait_for_error EXIT_COND - we only
need to wait until we leave the reset-in-progress wedged state.
v3: Don't play tricks with barriers in the throttle ioctl, the
spin_unlock is barrier enough.
I've also considered using a little helper to grab the current
reset_counter, but then decided that hiding the atomic_read isn't a
great idea, since having it explicitly show up in the code is a nice
remainder to reviews to check the memory barriers.
v4: Add a comment to explain why we need to fall through in
__wait_seqno in the end variable assignments.
v5: Review from Damien:
- s/smb/smp/ in a comment
- don't increment the reset counter after we've set it to WEDGED. Now
we (again) properly wedge the gpu when the reset fails.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-06 15:01:42 +07:00
|
|
|
/* We need to check whether any gpu reset happened in between
|
|
|
|
* the caller grabbing the seqno and now ... */
|
2013-09-25 23:34:55 +07:00
|
|
|
if (reset_counter != atomic_read(&dev_priv->gpu_error.reset_counter)) {
|
|
|
|
/* ... but upgrade the -EAGAIN to an -EIO if the gpu
|
|
|
|
* is truely gone. */
|
|
|
|
ret = i915_gem_check_wedge(&dev_priv->gpu_error, interruptible);
|
|
|
|
if (ret == 0)
|
|
|
|
ret = -EAGAIN;
|
|
|
|
break;
|
|
|
|
}
|
drm/i915: create a race-free reset detection
With the previous patch the state transition handling of the reset
code itself is now (hopefully) race free and solid. But that still
leaves out everyone else - with the various lock-free wait paths
we have there's the possibility that the reset happens between the
point where we read the seqno we should wait on and the actual wait.
And if __wait_seqno then never sees the RESET_IN_PROGRESS state, we'll
happily wait for a seqno which will in all likelyhood never signal.
In practice this is not a big problem since the X server gets
constantly interrupted, and can then submit more work (hopefully) to
unblock everyone else: As soon as a new seqno write lands, all waiters
will unblock. But running the i-g-t reset testcase ZZ_hangman can
expose this race, especially on slower hw with fewer cpu cores.
Now looking forward to ARB_robustness and friends that's not the best
possible behaviour, hence this patch adds a reset_counter to be able
to detect any reset, even if a given thread never observed the
in-progress state.
The important part is to correctly order things:
- The write side needs to increment the counter after any seqno gets
reset. Hence we need to do that at the end of the reset work, and
again wake everyone up. We also need to place a barrier in between
any possible seqno changes and the counter increment, since any
unlock operations only guarantee that nothing leaks out, but not
that at later load operation gets moved ahead.
- On the read side we need to ensure that no reset can sneak in and
invalidate the seqno. In all cases we can use the one-sided barrier
that unlock operations guarantee (of the lock protecting the
respective seqno/ring pair) to ensure correct ordering. Hence it is
sufficient to place the atomic read before the mutex/spin_unlock and
no additional barriers are required.
The end-result of all this is that we need to wake up everyone twice
in a reset operation:
- First, before the reset starts, to get any lockholders of the locks,
so that the reset can proceed.
- Second, after the reset is completed, to allow waiters to properly
and reliably detect the reset condition and bail out.
I admit that this entire reset_counter thing smells a bit like
overkill, but I think it's justified since it makes it really explicit
what the bail-out condition is. And we need a reset counter anyway to
implement ARB_robustness, and imo with finer-grained locking on the
horizont this is the most resilient scheme I could think of.
v2: Drop spurious change in the wait_for_error EXIT_COND - we only
need to wait until we leave the reset-in-progress wedged state.
v3: Don't play tricks with barriers in the throttle ioctl, the
spin_unlock is barrier enough.
I've also considered using a little helper to grab the current
reset_counter, but then decided that hiding the atomic_read isn't a
great idea, since having it explicitly show up in the code is a nice
remainder to reviews to check the memory barriers.
v4: Add a comment to explain why we need to fall through in
__wait_seqno in the end variable assignments.
v5: Review from Damien:
- s/smb/smp/ in a comment
- don't increment the reset counter after we've set it to WEDGED. Now
we (again) properly wedge the gpu when the reset fails.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-06 15:01:42 +07:00
|
|
|
|
2013-09-25 23:34:55 +07:00
|
|
|
if (i915_seqno_passed(ring->get_seqno(ring, false), seqno)) {
|
|
|
|
ret = 0;
|
|
|
|
break;
|
|
|
|
}
|
2012-08-24 15:35:08 +07:00
|
|
|
|
2013-09-25 23:34:55 +07:00
|
|
|
if (interruptible && signal_pending(current)) {
|
|
|
|
ret = -ERESTARTSYS;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2013-12-10 22:02:43 +07:00
|
|
|
if (timeout && time_after_eq(jiffies, timeout_expire)) {
|
2013-09-25 23:34:55 +07:00
|
|
|
ret = -ETIME;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
timer.function = NULL;
|
|
|
|
if (timeout || missed_irq(dev_priv, ring)) {
|
2013-12-10 22:02:43 +07:00
|
|
|
unsigned long expire;
|
|
|
|
|
2013-09-25 23:34:55 +07:00
|
|
|
setup_timer_on_stack(&timer, fake_irq, (unsigned long)current);
|
2013-12-10 22:02:43 +07:00
|
|
|
expire = missed_irq(dev_priv, ring) ? jiffies + 1 : timeout_expire;
|
2013-09-25 23:34:55 +07:00
|
|
|
mod_timer(&timer, expire);
|
|
|
|
}
|
|
|
|
|
2013-10-04 15:58:46 +07:00
|
|
|
io_schedule();
|
2013-09-25 23:34:55 +07:00
|
|
|
|
|
|
|
if (timer.function) {
|
|
|
|
del_singleshot_timer_sync(&timer);
|
|
|
|
destroy_timer_on_stack(&timer);
|
|
|
|
}
|
|
|
|
}
|
2012-08-24 15:35:08 +07:00
|
|
|
getrawmonotonic(&now);
|
2013-09-25 23:34:55 +07:00
|
|
|
trace_i915_gem_request_wait_end(ring, seqno);
|
2012-08-24 15:35:08 +07:00
|
|
|
|
|
|
|
ring->irq_put(ring);
|
2013-09-25 23:34:55 +07:00
|
|
|
|
|
|
|
finish_wait(&ring->irq_queue, &wait);
|
2012-08-24 15:35:08 +07:00
|
|
|
|
|
|
|
if (timeout) {
|
|
|
|
struct timespec sleep_time = timespec_sub(now, before);
|
|
|
|
*timeout = timespec_sub(*timeout, sleep_time);
|
2013-04-26 20:22:46 +07:00
|
|
|
if (!timespec_valid(timeout)) /* i.e. negative time remains */
|
|
|
|
set_normalized_timespec(timeout, 0, 0);
|
2012-08-24 15:35:08 +07:00
|
|
|
}
|
|
|
|
|
2013-09-25 23:34:55 +07:00
|
|
|
return ret;
|
2012-08-24 15:35:08 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Waits for a sequence number to be signaled, and cleans up the
|
|
|
|
* request and object lists appropriately for that event.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
i915_wait_seqno(struct intel_ring_buffer *ring, uint32_t seqno)
|
|
|
|
{
|
|
|
|
struct drm_device *dev = ring->dev;
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
|
|
|
bool interruptible = dev_priv->mm.interruptible;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
BUG_ON(!mutex_is_locked(&dev->struct_mutex));
|
|
|
|
BUG_ON(seqno == 0);
|
|
|
|
|
2012-11-14 23:14:05 +07:00
|
|
|
ret = i915_gem_check_wedge(&dev_priv->gpu_error, interruptible);
|
2012-08-24 15:35:08 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ret = i915_gem_check_olr(ring, seqno);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
drm/i915: create a race-free reset detection
With the previous patch the state transition handling of the reset
code itself is now (hopefully) race free and solid. But that still
leaves out everyone else - with the various lock-free wait paths
we have there's the possibility that the reset happens between the
point where we read the seqno we should wait on and the actual wait.
And if __wait_seqno then never sees the RESET_IN_PROGRESS state, we'll
happily wait for a seqno which will in all likelyhood never signal.
In practice this is not a big problem since the X server gets
constantly interrupted, and can then submit more work (hopefully) to
unblock everyone else: As soon as a new seqno write lands, all waiters
will unblock. But running the i-g-t reset testcase ZZ_hangman can
expose this race, especially on slower hw with fewer cpu cores.
Now looking forward to ARB_robustness and friends that's not the best
possible behaviour, hence this patch adds a reset_counter to be able
to detect any reset, even if a given thread never observed the
in-progress state.
The important part is to correctly order things:
- The write side needs to increment the counter after any seqno gets
reset. Hence we need to do that at the end of the reset work, and
again wake everyone up. We also need to place a barrier in between
any possible seqno changes and the counter increment, since any
unlock operations only guarantee that nothing leaks out, but not
that at later load operation gets moved ahead.
- On the read side we need to ensure that no reset can sneak in and
invalidate the seqno. In all cases we can use the one-sided barrier
that unlock operations guarantee (of the lock protecting the
respective seqno/ring pair) to ensure correct ordering. Hence it is
sufficient to place the atomic read before the mutex/spin_unlock and
no additional barriers are required.
The end-result of all this is that we need to wake up everyone twice
in a reset operation:
- First, before the reset starts, to get any lockholders of the locks,
so that the reset can proceed.
- Second, after the reset is completed, to allow waiters to properly
and reliably detect the reset condition and bail out.
I admit that this entire reset_counter thing smells a bit like
overkill, but I think it's justified since it makes it really explicit
what the bail-out condition is. And we need a reset counter anyway to
implement ARB_robustness, and imo with finer-grained locking on the
horizont this is the most resilient scheme I could think of.
v2: Drop spurious change in the wait_for_error EXIT_COND - we only
need to wait until we leave the reset-in-progress wedged state.
v3: Don't play tricks with barriers in the throttle ioctl, the
spin_unlock is barrier enough.
I've also considered using a little helper to grab the current
reset_counter, but then decided that hiding the atomic_read isn't a
great idea, since having it explicitly show up in the code is a nice
remainder to reviews to check the memory barriers.
v4: Add a comment to explain why we need to fall through in
__wait_seqno in the end variable assignments.
v5: Review from Damien:
- s/smb/smp/ in a comment
- don't increment the reset counter after we've set it to WEDGED. Now
we (again) properly wedge the gpu when the reset fails.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-06 15:01:42 +07:00
|
|
|
return __wait_seqno(ring, seqno,
|
|
|
|
atomic_read(&dev_priv->gpu_error.reset_counter),
|
drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-25 23:34:56 +07:00
|
|
|
interruptible, NULL, NULL);
|
2012-08-24 15:35:08 +07:00
|
|
|
}
|
|
|
|
|
2013-06-30 04:05:26 +07:00
|
|
|
static int
|
|
|
|
i915_gem_object_wait_rendering__tail(struct drm_i915_gem_object *obj,
|
|
|
|
struct intel_ring_buffer *ring)
|
|
|
|
{
|
|
|
|
i915_gem_retire_requests_ring(ring);
|
|
|
|
|
|
|
|
/* Manually manage the write flush as we may have not yet
|
|
|
|
* retired the buffer.
|
|
|
|
*
|
|
|
|
* Note that the last_write_seqno is always the earlier of
|
|
|
|
* the two (read/write) seqno, so if we haved successfully waited,
|
|
|
|
* we know we have passed the last write.
|
|
|
|
*/
|
|
|
|
obj->last_write_seqno = 0;
|
|
|
|
obj->base.write_domain &= ~I915_GEM_GPU_DOMAINS;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-08-24 15:35:08 +07:00
|
|
|
/**
|
|
|
|
* Ensures that all rendering to the object has completed and the object is
|
|
|
|
* safe to unbind from the GTT or access from the CPU.
|
|
|
|
*/
|
|
|
|
static __must_check int
|
|
|
|
i915_gem_object_wait_rendering(struct drm_i915_gem_object *obj,
|
|
|
|
bool readonly)
|
|
|
|
{
|
|
|
|
struct intel_ring_buffer *ring = obj->ring;
|
|
|
|
u32 seqno;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
seqno = readonly ? obj->last_write_seqno : obj->last_read_seqno;
|
|
|
|
if (seqno == 0)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
ret = i915_wait_seqno(ring, seqno);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2013-06-30 04:05:26 +07:00
|
|
|
return i915_gem_object_wait_rendering__tail(obj, ring);
|
2012-08-24 15:35:08 +07:00
|
|
|
}
|
|
|
|
|
2012-08-24 15:35:09 +07:00
|
|
|
/* A nonblocking variant of the above wait. This is a highly dangerous routine
|
|
|
|
* as the object state may change during this call.
|
|
|
|
*/
|
|
|
|
static __must_check int
|
|
|
|
i915_gem_object_wait_rendering__nonblocking(struct drm_i915_gem_object *obj,
|
drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-25 23:34:56 +07:00
|
|
|
struct drm_file *file,
|
2012-08-24 15:35:09 +07:00
|
|
|
bool readonly)
|
|
|
|
{
|
|
|
|
struct drm_device *dev = obj->base.dev;
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
|
|
|
struct intel_ring_buffer *ring = obj->ring;
|
drm/i915: create a race-free reset detection
With the previous patch the state transition handling of the reset
code itself is now (hopefully) race free and solid. But that still
leaves out everyone else - with the various lock-free wait paths
we have there's the possibility that the reset happens between the
point where we read the seqno we should wait on and the actual wait.
And if __wait_seqno then never sees the RESET_IN_PROGRESS state, we'll
happily wait for a seqno which will in all likelyhood never signal.
In practice this is not a big problem since the X server gets
constantly interrupted, and can then submit more work (hopefully) to
unblock everyone else: As soon as a new seqno write lands, all waiters
will unblock. But running the i-g-t reset testcase ZZ_hangman can
expose this race, especially on slower hw with fewer cpu cores.
Now looking forward to ARB_robustness and friends that's not the best
possible behaviour, hence this patch adds a reset_counter to be able
to detect any reset, even if a given thread never observed the
in-progress state.
The important part is to correctly order things:
- The write side needs to increment the counter after any seqno gets
reset. Hence we need to do that at the end of the reset work, and
again wake everyone up. We also need to place a barrier in between
any possible seqno changes and the counter increment, since any
unlock operations only guarantee that nothing leaks out, but not
that at later load operation gets moved ahead.
- On the read side we need to ensure that no reset can sneak in and
invalidate the seqno. In all cases we can use the one-sided barrier
that unlock operations guarantee (of the lock protecting the
respective seqno/ring pair) to ensure correct ordering. Hence it is
sufficient to place the atomic read before the mutex/spin_unlock and
no additional barriers are required.
The end-result of all this is that we need to wake up everyone twice
in a reset operation:
- First, before the reset starts, to get any lockholders of the locks,
so that the reset can proceed.
- Second, after the reset is completed, to allow waiters to properly
and reliably detect the reset condition and bail out.
I admit that this entire reset_counter thing smells a bit like
overkill, but I think it's justified since it makes it really explicit
what the bail-out condition is. And we need a reset counter anyway to
implement ARB_robustness, and imo with finer-grained locking on the
horizont this is the most resilient scheme I could think of.
v2: Drop spurious change in the wait_for_error EXIT_COND - we only
need to wait until we leave the reset-in-progress wedged state.
v3: Don't play tricks with barriers in the throttle ioctl, the
spin_unlock is barrier enough.
I've also considered using a little helper to grab the current
reset_counter, but then decided that hiding the atomic_read isn't a
great idea, since having it explicitly show up in the code is a nice
remainder to reviews to check the memory barriers.
v4: Add a comment to explain why we need to fall through in
__wait_seqno in the end variable assignments.
v5: Review from Damien:
- s/smb/smp/ in a comment
- don't increment the reset counter after we've set it to WEDGED. Now
we (again) properly wedge the gpu when the reset fails.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-06 15:01:42 +07:00
|
|
|
unsigned reset_counter;
|
2012-08-24 15:35:09 +07:00
|
|
|
u32 seqno;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
BUG_ON(!mutex_is_locked(&dev->struct_mutex));
|
|
|
|
BUG_ON(!dev_priv->mm.interruptible);
|
|
|
|
|
|
|
|
seqno = readonly ? obj->last_write_seqno : obj->last_read_seqno;
|
|
|
|
if (seqno == 0)
|
|
|
|
return 0;
|
|
|
|
|
2012-11-14 23:14:05 +07:00
|
|
|
ret = i915_gem_check_wedge(&dev_priv->gpu_error, true);
|
2012-08-24 15:35:09 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ret = i915_gem_check_olr(ring, seqno);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
drm/i915: create a race-free reset detection
With the previous patch the state transition handling of the reset
code itself is now (hopefully) race free and solid. But that still
leaves out everyone else - with the various lock-free wait paths
we have there's the possibility that the reset happens between the
point where we read the seqno we should wait on and the actual wait.
And if __wait_seqno then never sees the RESET_IN_PROGRESS state, we'll
happily wait for a seqno which will in all likelyhood never signal.
In practice this is not a big problem since the X server gets
constantly interrupted, and can then submit more work (hopefully) to
unblock everyone else: As soon as a new seqno write lands, all waiters
will unblock. But running the i-g-t reset testcase ZZ_hangman can
expose this race, especially on slower hw with fewer cpu cores.
Now looking forward to ARB_robustness and friends that's not the best
possible behaviour, hence this patch adds a reset_counter to be able
to detect any reset, even if a given thread never observed the
in-progress state.
The important part is to correctly order things:
- The write side needs to increment the counter after any seqno gets
reset. Hence we need to do that at the end of the reset work, and
again wake everyone up. We also need to place a barrier in between
any possible seqno changes and the counter increment, since any
unlock operations only guarantee that nothing leaks out, but not
that at later load operation gets moved ahead.
- On the read side we need to ensure that no reset can sneak in and
invalidate the seqno. In all cases we can use the one-sided barrier
that unlock operations guarantee (of the lock protecting the
respective seqno/ring pair) to ensure correct ordering. Hence it is
sufficient to place the atomic read before the mutex/spin_unlock and
no additional barriers are required.
The end-result of all this is that we need to wake up everyone twice
in a reset operation:
- First, before the reset starts, to get any lockholders of the locks,
so that the reset can proceed.
- Second, after the reset is completed, to allow waiters to properly
and reliably detect the reset condition and bail out.
I admit that this entire reset_counter thing smells a bit like
overkill, but I think it's justified since it makes it really explicit
what the bail-out condition is. And we need a reset counter anyway to
implement ARB_robustness, and imo with finer-grained locking on the
horizont this is the most resilient scheme I could think of.
v2: Drop spurious change in the wait_for_error EXIT_COND - we only
need to wait until we leave the reset-in-progress wedged state.
v3: Don't play tricks with barriers in the throttle ioctl, the
spin_unlock is barrier enough.
I've also considered using a little helper to grab the current
reset_counter, but then decided that hiding the atomic_read isn't a
great idea, since having it explicitly show up in the code is a nice
remainder to reviews to check the memory barriers.
v4: Add a comment to explain why we need to fall through in
__wait_seqno in the end variable assignments.
v5: Review from Damien:
- s/smb/smp/ in a comment
- don't increment the reset counter after we've set it to WEDGED. Now
we (again) properly wedge the gpu when the reset fails.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-06 15:01:42 +07:00
|
|
|
reset_counter = atomic_read(&dev_priv->gpu_error.reset_counter);
|
2012-08-24 15:35:09 +07:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-25 23:34:56 +07:00
|
|
|
ret = __wait_seqno(ring, seqno, reset_counter, true, NULL, file->driver_priv);
|
2012-08-24 15:35:09 +07:00
|
|
|
mutex_lock(&dev->struct_mutex);
|
2013-06-30 04:05:26 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
2012-08-24 15:35:09 +07:00
|
|
|
|
2013-06-30 04:05:26 +07:00
|
|
|
return i915_gem_object_wait_rendering__tail(obj, ring);
|
2012-08-24 15:35:09 +07:00
|
|
|
}
|
|
|
|
|
2008-07-31 02:06:12 +07:00
|
|
|
/**
|
2008-11-11 01:53:25 +07:00
|
|
|
* Called when user space prepares to use an object with the CPU, either
|
|
|
|
* through the mmap ioctl's mapping or a GTT mapping.
|
2008-07-31 02:06:12 +07:00
|
|
|
*/
|
|
|
|
int
|
|
|
|
i915_gem_set_domain_ioctl(struct drm_device *dev, void *data,
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_file *file)
|
2008-07-31 02:06:12 +07:00
|
|
|
{
|
|
|
|
struct drm_i915_gem_set_domain *args = data;
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_i915_gem_object *obj;
|
2008-11-11 01:53:25 +07:00
|
|
|
uint32_t read_domains = args->read_domains;
|
|
|
|
uint32_t write_domain = args->write_domain;
|
2008-07-31 02:06:12 +07:00
|
|
|
int ret;
|
|
|
|
|
2008-11-11 01:53:25 +07:00
|
|
|
/* Only handle setting domains to types used by the CPU. */
|
2009-06-06 15:46:02 +07:00
|
|
|
if (write_domain & I915_GEM_GPU_DOMAINS)
|
2008-11-11 01:53:25 +07:00
|
|
|
return -EINVAL;
|
|
|
|
|
2009-06-06 15:46:02 +07:00
|
|
|
if (read_domains & I915_GEM_GPU_DOMAINS)
|
2008-11-11 01:53:25 +07:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* Having something in the write domain implies it's in the read
|
|
|
|
* domain, and only that read domain. Enforce that in the request.
|
|
|
|
*/
|
|
|
|
if (write_domain != 0 && read_domains != write_domain)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2010-09-25 17:22:51 +07:00
|
|
|
ret = i915_mutex_lock_interruptible(dev);
|
2010-10-17 15:45:41 +07:00
|
|
|
if (ret)
|
2010-09-25 17:22:51 +07:00
|
|
|
return ret;
|
2010-10-17 15:45:41 +07:00
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
obj = to_intel_bo(drm_gem_object_lookup(dev, file, args->handle));
|
2011-02-19 18:31:06 +07:00
|
|
|
if (&obj->base == NULL) {
|
2010-10-17 15:45:41 +07:00
|
|
|
ret = -ENOENT;
|
|
|
|
goto unlock;
|
2010-09-25 17:22:51 +07:00
|
|
|
}
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2012-08-24 15:35:09 +07:00
|
|
|
/* Try to flush the object off the GPU without holding the lock.
|
|
|
|
* We will repeat the flush holding the lock in the normal manner
|
|
|
|
* to catch cases where we are gazumped.
|
|
|
|
*/
|
drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-25 23:34:56 +07:00
|
|
|
ret = i915_gem_object_wait_rendering__nonblocking(obj, file, !write_domain);
|
2012-08-24 15:35:09 +07:00
|
|
|
if (ret)
|
|
|
|
goto unref;
|
|
|
|
|
2008-11-11 01:53:25 +07:00
|
|
|
if (read_domains & I915_GEM_DOMAIN_GTT) {
|
|
|
|
ret = i915_gem_object_set_to_gtt_domain(obj, write_domain != 0);
|
2008-11-27 04:58:13 +07:00
|
|
|
|
|
|
|
/* Silently promote "you're not bound, there was nothing to do"
|
|
|
|
* to success, since the client was just asking us to
|
|
|
|
* make sure everything was done.
|
|
|
|
*/
|
|
|
|
if (ret == -EINVAL)
|
|
|
|
ret = 0;
|
2008-11-11 01:53:25 +07:00
|
|
|
} else {
|
2008-11-15 04:35:19 +07:00
|
|
|
ret = i915_gem_object_set_to_cpu_domain(obj, write_domain != 0);
|
2008-11-11 01:53:25 +07:00
|
|
|
}
|
|
|
|
|
2012-08-24 15:35:09 +07:00
|
|
|
unref:
|
2010-11-09 02:18:58 +07:00
|
|
|
drm_gem_object_unreference(&obj->base);
|
2010-10-17 15:45:41 +07:00
|
|
|
unlock:
|
2008-07-31 02:06:12 +07:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Called when user space has done writes to this buffer
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
i915_gem_sw_finish_ioctl(struct drm_device *dev, void *data,
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_file *file)
|
2008-07-31 02:06:12 +07:00
|
|
|
{
|
|
|
|
struct drm_i915_gem_sw_finish *args = data;
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_i915_gem_object *obj;
|
2008-07-31 02:06:12 +07:00
|
|
|
int ret = 0;
|
|
|
|
|
2010-09-25 17:22:51 +07:00
|
|
|
ret = i915_mutex_lock_interruptible(dev);
|
2010-10-17 15:45:41 +07:00
|
|
|
if (ret)
|
2010-09-25 17:22:51 +07:00
|
|
|
return ret;
|
2010-10-17 15:45:41 +07:00
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
obj = to_intel_bo(drm_gem_object_lookup(dev, file, args->handle));
|
2011-02-19 18:31:06 +07:00
|
|
|
if (&obj->base == NULL) {
|
2010-10-17 15:45:41 +07:00
|
|
|
ret = -ENOENT;
|
|
|
|
goto unlock;
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Pinned buffers may be scanout, so flush the cache */
|
2013-08-09 18:26:45 +07:00
|
|
|
if (obj->pin_display)
|
|
|
|
i915_gem_object_flush_cpu_write_domain(obj, true);
|
2008-11-15 04:35:19 +07:00
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
drm_gem_object_unreference(&obj->base);
|
2010-10-17 15:45:41 +07:00
|
|
|
unlock:
|
2008-07-31 02:06:12 +07:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Maps the contents of an object, returning the address it is mapped
|
|
|
|
* into.
|
|
|
|
*
|
|
|
|
* While the mapping holds a reference on the contents of the object, it doesn't
|
|
|
|
* imply a ref on the object itself.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_file *file)
|
2008-07-31 02:06:12 +07:00
|
|
|
{
|
|
|
|
struct drm_i915_gem_mmap *args = data;
|
|
|
|
struct drm_gem_object *obj;
|
|
|
|
unsigned long addr;
|
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
obj = drm_gem_object_lookup(dev, file, args->handle);
|
2008-07-31 02:06:12 +07:00
|
|
|
if (obj == NULL)
|
2010-08-04 20:19:46 +07:00
|
|
|
return -ENOENT;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2012-05-10 20:25:09 +07:00
|
|
|
/* prime objects have no backing filp to GEM mmap
|
|
|
|
* pages from.
|
|
|
|
*/
|
|
|
|
if (!obj->filp) {
|
|
|
|
drm_gem_object_unreference_unlocked(obj);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2012-04-21 07:13:58 +07:00
|
|
|
addr = vm_mmap(obj->filp, 0, args->size,
|
2008-07-31 02:06:12 +07:00
|
|
|
PROT_READ | PROT_WRITE, MAP_SHARED,
|
|
|
|
args->offset);
|
2010-02-09 12:49:12 +07:00
|
|
|
drm_gem_object_unreference_unlocked(obj);
|
2008-07-31 02:06:12 +07:00
|
|
|
if (IS_ERR((void *)addr))
|
|
|
|
return addr;
|
|
|
|
|
|
|
|
args->addr_ptr = (uint64_t) addr;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-11-13 01:03:55 +07:00
|
|
|
/**
|
|
|
|
* i915_gem_fault - fault a page into the GTT
|
|
|
|
* vma: VMA in question
|
|
|
|
* vmf: fault info
|
|
|
|
*
|
|
|
|
* The fault handler is set up by drm_gem_mmap() when a object is GTT mapped
|
|
|
|
* from userspace. The fault handler takes care of binding the object to
|
|
|
|
* the GTT (if needed), allocating and programming a fence register (again,
|
|
|
|
* only if needed based on whether the old reg is still valid or the object
|
|
|
|
* is tiled) and inserting a new PTE into the faulting process.
|
|
|
|
*
|
|
|
|
* Note that the faulting process may involve evicting existing objects
|
|
|
|
* from the GTT and/or fence registers to make room. So performance may
|
|
|
|
* suffer if the GTT working set is large or there are few fence registers
|
|
|
|
* left.
|
|
|
|
*/
|
|
|
|
int i915_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
|
|
|
|
{
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_i915_gem_object *obj = to_intel_bo(vma->vm_private_data);
|
|
|
|
struct drm_device *dev = obj->base.dev;
|
2010-08-08 03:45:03 +07:00
|
|
|
drm_i915_private_t *dev_priv = dev->dev_private;
|
2008-11-13 01:03:55 +07:00
|
|
|
pgoff_t page_offset;
|
|
|
|
unsigned long pfn;
|
|
|
|
int ret = 0;
|
2009-01-27 08:10:45 +07:00
|
|
|
bool write = !!(vmf->flags & FAULT_FLAG_WRITE);
|
2008-11-13 01:03:55 +07:00
|
|
|
|
2013-11-28 03:20:34 +07:00
|
|
|
intel_runtime_pm_get(dev_priv);
|
|
|
|
|
2008-11-13 01:03:55 +07:00
|
|
|
/* We don't use vmf->pgoff since that has the fake offset */
|
|
|
|
page_offset = ((unsigned long)vmf->virtual_address - vma->vm_start) >>
|
|
|
|
PAGE_SHIFT;
|
|
|
|
|
2011-02-07 20:09:31 +07:00
|
|
|
ret = i915_mutex_lock_interruptible(dev);
|
|
|
|
if (ret)
|
|
|
|
goto out;
|
2010-09-25 03:15:47 +07:00
|
|
|
|
2011-02-03 18:57:46 +07:00
|
|
|
trace_i915_gem_object_fault(obj, page_offset, true, write);
|
|
|
|
|
2012-12-16 19:43:36 +07:00
|
|
|
/* Access to snoopable pages through the GTT is incoherent. */
|
|
|
|
if (obj->cache_level != I915_CACHE_NONE && !HAS_LLC(dev)) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
|
2011-02-07 20:09:31 +07:00
|
|
|
/* Now bind it into the GTT if needed */
|
2013-08-01 06:59:58 +07:00
|
|
|
ret = i915_gem_obj_ggtt_pin(obj, 0, true, false);
|
2012-11-20 17:45:17 +07:00
|
|
|
if (ret)
|
|
|
|
goto unlock;
|
2010-10-28 20:44:08 +07:00
|
|
|
|
2012-11-20 17:45:17 +07:00
|
|
|
ret = i915_gem_object_set_to_gtt_domain(obj, write);
|
|
|
|
if (ret)
|
|
|
|
goto unpin;
|
2012-02-16 05:50:22 +07:00
|
|
|
|
2012-04-17 21:31:24 +07:00
|
|
|
ret = i915_gem_object_get_fence(obj);
|
2010-11-10 23:40:20 +07:00
|
|
|
if (ret)
|
2012-11-20 17:45:17 +07:00
|
|
|
goto unpin;
|
2010-08-08 03:45:03 +07:00
|
|
|
|
2010-11-24 19:23:44 +07:00
|
|
|
obj->fault_mappable = true;
|
|
|
|
|
2013-07-06 04:41:04 +07:00
|
|
|
pfn = dev_priv->gtt.mappable_base + i915_gem_obj_ggtt_offset(obj);
|
|
|
|
pfn >>= PAGE_SHIFT;
|
|
|
|
pfn += page_offset;
|
2008-11-13 01:03:55 +07:00
|
|
|
|
|
|
|
/* Finally, remap it using the new GTT offset */
|
|
|
|
ret = vm_insert_pfn(vma, (unsigned long)vmf->virtual_address, pfn);
|
2012-11-20 17:45:17 +07:00
|
|
|
unpin:
|
|
|
|
i915_gem_object_unpin(obj);
|
2009-09-23 06:43:56 +07:00
|
|
|
unlock:
|
2008-11-13 01:03:55 +07:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
2011-02-07 20:09:31 +07:00
|
|
|
out:
|
2008-11-13 01:03:55 +07:00
|
|
|
switch (ret) {
|
2011-02-07 20:09:31 +07:00
|
|
|
case -EIO:
|
2012-07-05 03:18:42 +07:00
|
|
|
/* If this -EIO is due to a gpu hang, give the reset code a
|
|
|
|
* chance to clean up the mess. Otherwise return the proper
|
|
|
|
* SIGBUS. */
|
2013-11-28 03:20:34 +07:00
|
|
|
if (i915_terminally_wedged(&dev_priv->gpu_error)) {
|
|
|
|
ret = VM_FAULT_SIGBUS;
|
|
|
|
break;
|
|
|
|
}
|
2010-11-07 16:18:22 +07:00
|
|
|
case -EAGAIN:
|
2013-09-12 22:57:28 +07:00
|
|
|
/*
|
|
|
|
* EAGAIN means the gpu is hung and we'll wait for the error
|
|
|
|
* handler to reset everything when re-faulting in
|
|
|
|
* i915_mutex_lock_interruptible.
|
2011-02-07 20:09:31 +07:00
|
|
|
*/
|
2009-09-23 06:43:56 +07:00
|
|
|
case 0:
|
|
|
|
case -ERESTARTSYS:
|
2011-02-12 03:31:19 +07:00
|
|
|
case -EINTR:
|
2012-10-03 21:15:26 +07:00
|
|
|
case -EBUSY:
|
|
|
|
/*
|
|
|
|
* EBUSY is ok: this just means that another thread
|
|
|
|
* already did the job.
|
|
|
|
*/
|
2013-11-28 03:20:34 +07:00
|
|
|
ret = VM_FAULT_NOPAGE;
|
|
|
|
break;
|
2008-11-13 01:03:55 +07:00
|
|
|
case -ENOMEM:
|
2013-11-28 03:20:34 +07:00
|
|
|
ret = VM_FAULT_OOM;
|
|
|
|
break;
|
2012-10-17 16:17:16 +07:00
|
|
|
case -ENOSPC:
|
2013-11-28 03:20:34 +07:00
|
|
|
ret = VM_FAULT_SIGBUS;
|
|
|
|
break;
|
2008-11-13 01:03:55 +07:00
|
|
|
default:
|
2012-10-17 16:17:16 +07:00
|
|
|
WARN_ONCE(ret, "unhandled error in i915_gem_fault: %i\n", ret);
|
2013-11-28 03:20:34 +07:00
|
|
|
ret = VM_FAULT_SIGBUS;
|
|
|
|
break;
|
2008-11-13 01:03:55 +07:00
|
|
|
}
|
2013-11-28 03:20:34 +07:00
|
|
|
|
|
|
|
intel_runtime_pm_put(dev_priv);
|
|
|
|
return ret;
|
2008-11-13 01:03:55 +07:00
|
|
|
}
|
|
|
|
|
2009-07-10 14:18:50 +07:00
|
|
|
/**
|
|
|
|
* i915_gem_release_mmap - remove physical page mappings
|
|
|
|
* @obj: obj in question
|
|
|
|
*
|
tree-wide: fix assorted typos all over the place
That is "success", "unknown", "through", "performance", "[re|un]mapping"
, "access", "default", "reasonable", "[con]currently", "temperature"
, "channel", "[un]used", "application", "example","hierarchy", "therefore"
, "[over|under]flow", "contiguous", "threshold", "enough" and others.
Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2009-11-14 22:09:05 +07:00
|
|
|
* Preserve the reservation of the mmapping with the DRM core code, but
|
2009-07-10 14:18:50 +07:00
|
|
|
* relinquish ownership of the pages back to the system.
|
|
|
|
*
|
|
|
|
* It is vital that we remove the page mapping if we have mapped a tiled
|
|
|
|
* object through the GTT and then lose the fence register due to
|
|
|
|
* resource pressure. Similarly if the object has been moved out of the
|
|
|
|
* aperture, than pages mapped into userspace must be revoked. Removing the
|
|
|
|
* mapping will then trigger a page fault on the next user access, allowing
|
|
|
|
* fixup by i915_gem_fault().
|
|
|
|
*/
|
2009-07-11 03:02:26 +07:00
|
|
|
void
|
2010-11-09 02:18:58 +07:00
|
|
|
i915_gem_release_mmap(struct drm_i915_gem_object *obj)
|
2009-07-10 14:18:50 +07:00
|
|
|
{
|
2010-11-24 19:23:44 +07:00
|
|
|
if (!obj->fault_mappable)
|
|
|
|
return;
|
2009-07-10 14:18:50 +07:00
|
|
|
|
2013-07-25 02:10:03 +07:00
|
|
|
drm_vma_node_unmap(&obj->base.vma_node, obj->base.dev->dev_mapping);
|
2010-11-24 19:23:44 +07:00
|
|
|
obj->fault_mappable = false;
|
2009-07-10 14:18:50 +07:00
|
|
|
}
|
|
|
|
|
2013-01-08 02:47:35 +07:00
|
|
|
uint32_t
|
2011-07-19 03:11:49 +07:00
|
|
|
i915_gem_get_gtt_size(struct drm_device *dev, uint32_t size, int tiling_mode)
|
2010-11-09 18:47:32 +07:00
|
|
|
{
|
2011-07-19 03:11:49 +07:00
|
|
|
uint32_t gtt_size;
|
2010-11-09 18:47:32 +07:00
|
|
|
|
|
|
|
if (INTEL_INFO(dev)->gen >= 4 ||
|
2011-07-19 03:11:49 +07:00
|
|
|
tiling_mode == I915_TILING_NONE)
|
|
|
|
return size;
|
2010-11-09 18:47:32 +07:00
|
|
|
|
|
|
|
/* Previous chips need a power-of-two fence region when tiling */
|
|
|
|
if (INTEL_INFO(dev)->gen == 3)
|
2011-07-19 03:11:49 +07:00
|
|
|
gtt_size = 1024*1024;
|
2010-11-09 18:47:32 +07:00
|
|
|
else
|
2011-07-19 03:11:49 +07:00
|
|
|
gtt_size = 512*1024;
|
2010-11-09 18:47:32 +07:00
|
|
|
|
2011-07-19 03:11:49 +07:00
|
|
|
while (gtt_size < size)
|
|
|
|
gtt_size <<= 1;
|
2010-11-09 18:47:32 +07:00
|
|
|
|
2011-07-19 03:11:49 +07:00
|
|
|
return gtt_size;
|
2010-11-09 18:47:32 +07:00
|
|
|
}
|
|
|
|
|
2008-11-13 01:03:55 +07:00
|
|
|
/**
|
|
|
|
* i915_gem_get_gtt_alignment - return required GTT alignment for an object
|
|
|
|
* @obj: object to check
|
|
|
|
*
|
|
|
|
* Return the required GTT alignment for an object, taking into account
|
2010-11-15 04:32:36 +07:00
|
|
|
* potential fence register mapping.
|
2008-11-13 01:03:55 +07:00
|
|
|
*/
|
2013-01-08 02:47:33 +07:00
|
|
|
uint32_t
|
|
|
|
i915_gem_get_gtt_alignment(struct drm_device *dev, uint32_t size,
|
|
|
|
int tiling_mode, bool fenced)
|
2008-11-13 01:03:55 +07:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Minimum alignment is 4k (GTT page size), but might be greater
|
|
|
|
* if a fence register is needed for the object.
|
|
|
|
*/
|
2013-01-08 02:47:33 +07:00
|
|
|
if (INTEL_INFO(dev)->gen >= 4 || (!fenced && IS_G33(dev)) ||
|
2011-07-19 03:11:49 +07:00
|
|
|
tiling_mode == I915_TILING_NONE)
|
2008-11-13 01:03:55 +07:00
|
|
|
return 4096;
|
|
|
|
|
2010-09-25 03:15:47 +07:00
|
|
|
/*
|
|
|
|
* Previous chips need to be aligned to the size of the smallest
|
|
|
|
* fence register that can contain the object.
|
|
|
|
*/
|
2011-07-19 03:11:49 +07:00
|
|
|
return i915_gem_get_gtt_size(dev, size, tiling_mode);
|
2010-09-25 03:15:47 +07:00
|
|
|
}
|
|
|
|
|
2012-08-11 21:41:03 +07:00
|
|
|
static int i915_gem_object_create_mmap_offset(struct drm_i915_gem_object *obj)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
|
|
|
|
int ret;
|
|
|
|
|
2013-07-25 02:07:52 +07:00
|
|
|
if (drm_vma_node_has_offset(&obj->base.vma_node))
|
2012-08-11 21:41:03 +07:00
|
|
|
return 0;
|
|
|
|
|
2012-12-20 21:11:16 +07:00
|
|
|
dev_priv->mm.shrinker_no_lock_stealing = true;
|
|
|
|
|
2012-08-11 21:41:03 +07:00
|
|
|
ret = drm_gem_create_mmap_offset(&obj->base);
|
|
|
|
if (ret != -ENOSPC)
|
2012-12-20 21:11:16 +07:00
|
|
|
goto out;
|
2012-08-11 21:41:03 +07:00
|
|
|
|
|
|
|
/* Badly fragmented mmap space? The only way we can recover
|
|
|
|
* space is by destroying unwanted objects. We can't randomly release
|
|
|
|
* mmap_offsets as userspace expects them to be persistent for the
|
|
|
|
* lifetime of the objects. The closest we can is to release the
|
|
|
|
* offsets on purgeable objects by truncating it and marking it purged,
|
|
|
|
* which prevents userspace from ever using that object again.
|
|
|
|
*/
|
|
|
|
i915_gem_purge(dev_priv, obj->base.size >> PAGE_SHIFT);
|
|
|
|
ret = drm_gem_create_mmap_offset(&obj->base);
|
|
|
|
if (ret != -ENOSPC)
|
2012-12-20 21:11:16 +07:00
|
|
|
goto out;
|
2012-08-11 21:41:03 +07:00
|
|
|
|
|
|
|
i915_gem_shrink_all(dev_priv);
|
2012-12-20 21:11:16 +07:00
|
|
|
ret = drm_gem_create_mmap_offset(&obj->base);
|
|
|
|
out:
|
|
|
|
dev_priv->mm.shrinker_no_lock_stealing = false;
|
|
|
|
|
|
|
|
return ret;
|
2012-08-11 21:41:03 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void i915_gem_object_free_mmap_offset(struct drm_i915_gem_object *obj)
|
|
|
|
{
|
|
|
|
drm_gem_free_mmap_offset(&obj->base);
|
|
|
|
}
|
|
|
|
|
2008-11-13 01:03:55 +07:00
|
|
|
int
|
2011-02-07 09:16:14 +07:00
|
|
|
i915_gem_mmap_gtt(struct drm_file *file,
|
|
|
|
struct drm_device *dev,
|
|
|
|
uint32_t handle,
|
|
|
|
uint64_t *offset)
|
2008-11-13 01:03:55 +07:00
|
|
|
{
|
2010-10-27 23:37:08 +07:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_i915_gem_object *obj;
|
2008-11-13 01:03:55 +07:00
|
|
|
int ret;
|
|
|
|
|
2010-09-25 17:22:51 +07:00
|
|
|
ret = i915_mutex_lock_interruptible(dev);
|
2010-10-17 15:45:41 +07:00
|
|
|
if (ret)
|
2010-09-25 17:22:51 +07:00
|
|
|
return ret;
|
2008-11-13 01:03:55 +07:00
|
|
|
|
2011-02-07 09:16:14 +07:00
|
|
|
obj = to_intel_bo(drm_gem_object_lookup(dev, file, handle));
|
2011-02-19 18:31:06 +07:00
|
|
|
if (&obj->base == NULL) {
|
2010-10-17 15:45:41 +07:00
|
|
|
ret = -ENOENT;
|
|
|
|
goto unlock;
|
|
|
|
}
|
2008-11-13 01:03:55 +07:00
|
|
|
|
2013-01-18 03:45:15 +07:00
|
|
|
if (obj->base.size > dev_priv->gtt.mappable_end) {
|
2010-10-27 23:37:08 +07:00
|
|
|
ret = -E2BIG;
|
2011-11-01 13:16:21 +07:00
|
|
|
goto out;
|
2010-10-27 23:37:08 +07:00
|
|
|
}
|
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
if (obj->madv != I915_MADV_WILLNEED) {
|
2009-09-23 00:46:17 +07:00
|
|
|
DRM_ERROR("Attempting to mmap a purgeable buffer\n");
|
2010-10-17 15:45:41 +07:00
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
2009-09-23 00:46:17 +07:00
|
|
|
}
|
|
|
|
|
2012-08-11 21:41:03 +07:00
|
|
|
ret = i915_gem_object_create_mmap_offset(obj);
|
|
|
|
if (ret)
|
|
|
|
goto out;
|
2008-11-13 01:03:55 +07:00
|
|
|
|
2013-07-25 02:07:52 +07:00
|
|
|
*offset = drm_vma_node_offset_addr(&obj->base.vma_node);
|
2008-11-13 01:03:55 +07:00
|
|
|
|
2010-10-17 15:45:41 +07:00
|
|
|
out:
|
2010-11-09 02:18:58 +07:00
|
|
|
drm_gem_object_unreference(&obj->base);
|
2010-10-17 15:45:41 +07:00
|
|
|
unlock:
|
2008-11-13 01:03:55 +07:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
2010-10-17 15:45:41 +07:00
|
|
|
return ret;
|
2008-11-13 01:03:55 +07:00
|
|
|
}
|
|
|
|
|
2011-02-07 09:16:14 +07:00
|
|
|
/**
|
|
|
|
* i915_gem_mmap_gtt_ioctl - prepare an object for GTT mmap'ing
|
|
|
|
* @dev: DRM device
|
|
|
|
* @data: GTT mapping ioctl data
|
|
|
|
* @file: GEM object info
|
|
|
|
*
|
|
|
|
* Simply returns the fake offset to userspace so it can mmap it.
|
|
|
|
* The mmap call will end up in drm_gem_mmap(), which will set things
|
|
|
|
* up so we can get faults in the handler above.
|
|
|
|
*
|
|
|
|
* The fault handler will take care of binding the object into the GTT
|
|
|
|
* (since it may have been evicted to make room for something), allocating
|
|
|
|
* a fence register, and mapping the appropriate aperture address into
|
|
|
|
* userspace.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
i915_gem_mmap_gtt_ioctl(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file)
|
|
|
|
{
|
|
|
|
struct drm_i915_gem_mmap_gtt *args = data;
|
|
|
|
|
|
|
|
return i915_gem_mmap_gtt(file, dev, args->handle, &args->offset);
|
|
|
|
}
|
|
|
|
|
2012-08-20 15:23:20 +07:00
|
|
|
/* Immediately discard the backing storage */
|
|
|
|
static void
|
|
|
|
i915_gem_object_truncate(struct drm_i915_gem_object *obj)
|
2010-10-28 19:45:36 +07:00
|
|
|
{
|
|
|
|
struct inode *inode;
|
|
|
|
|
2012-08-11 21:41:05 +07:00
|
|
|
i915_gem_object_free_mmap_offset(obj);
|
2012-05-10 20:25:09 +07:00
|
|
|
|
2012-08-11 21:41:05 +07:00
|
|
|
if (obj->base.filp == NULL)
|
|
|
|
return;
|
2010-10-28 19:45:36 +07:00
|
|
|
|
2012-08-20 15:23:20 +07:00
|
|
|
/* Our goal here is to return as much of the memory as
|
|
|
|
* is possible back to the system as we are called from OOM.
|
|
|
|
* To do this we must instruct the shmfs to drop all of its
|
|
|
|
* backing pages, *now*.
|
|
|
|
*/
|
2013-01-24 05:07:38 +07:00
|
|
|
inode = file_inode(obj->base.filp);
|
2012-08-20 15:23:20 +07:00
|
|
|
shmem_truncate_range(inode, 0, (loff_t)-1);
|
2010-10-28 19:45:36 +07:00
|
|
|
|
2012-08-20 15:23:20 +07:00
|
|
|
obj->madv = __I915_MADV_PURGED;
|
|
|
|
}
|
2010-10-28 19:45:36 +07:00
|
|
|
|
2012-08-20 15:23:20 +07:00
|
|
|
static inline int
|
|
|
|
i915_gem_object_is_purgeable(struct drm_i915_gem_object *obj)
|
|
|
|
{
|
|
|
|
return obj->madv == I915_MADV_DONTNEED;
|
2010-10-28 19:45:36 +07:00
|
|
|
}
|
|
|
|
|
2010-09-27 21:51:07 +07:00
|
|
|
static void
|
2010-11-09 02:18:58 +07:00
|
|
|
i915_gem_object_put_pages_gtt(struct drm_i915_gem_object *obj)
|
2008-07-31 02:06:12 +07:00
|
|
|
{
|
2013-02-19 00:28:03 +07:00
|
|
|
struct sg_page_iter sg_iter;
|
|
|
|
int ret;
|
2012-05-10 20:25:09 +07:00
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
BUG_ON(obj->madv == __I915_MADV_PURGED);
|
2008-07-31 02:06:12 +07:00
|
|
|
|
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 16:40:46 +07:00
|
|
|
ret = i915_gem_object_set_to_cpu_domain(obj, true);
|
|
|
|
if (ret) {
|
|
|
|
/* In the event of a disaster, abandon all caches and
|
|
|
|
* hope for the best.
|
|
|
|
*/
|
|
|
|
WARN_ON(ret != -EIO);
|
2013-08-09 18:26:45 +07:00
|
|
|
i915_gem_clflush_object(obj, true);
|
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 16:40:46 +07:00
|
|
|
obj->base.read_domains = obj->base.write_domain = I915_GEM_DOMAIN_CPU;
|
|
|
|
}
|
|
|
|
|
2011-09-13 02:30:02 +07:00
|
|
|
if (i915_gem_object_needs_bit17_swizzle(obj))
|
2009-03-13 06:56:27 +07:00
|
|
|
i915_gem_object_save_bit_17_swizzle(obj);
|
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
if (obj->madv == I915_MADV_DONTNEED)
|
|
|
|
obj->dirty = 0;
|
2009-09-14 22:50:29 +07:00
|
|
|
|
2013-02-19 00:28:03 +07:00
|
|
|
for_each_sg_page(obj->pages->sgl, &sg_iter, obj->pages->nents, 0) {
|
2013-03-26 20:14:18 +07:00
|
|
|
struct page *page = sg_page_iter_page(&sg_iter);
|
2012-06-01 21:20:22 +07:00
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
if (obj->dirty)
|
2012-06-01 21:20:22 +07:00
|
|
|
set_page_dirty(page);
|
2009-09-14 22:50:29 +07:00
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
if (obj->madv == I915_MADV_WILLNEED)
|
2012-06-01 21:20:22 +07:00
|
|
|
mark_page_accessed(page);
|
2009-09-14 22:50:29 +07:00
|
|
|
|
2012-06-01 21:20:22 +07:00
|
|
|
page_cache_release(page);
|
2009-09-14 22:50:29 +07:00
|
|
|
}
|
2010-11-09 02:18:58 +07:00
|
|
|
obj->dirty = 0;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2012-06-01 21:20:22 +07:00
|
|
|
sg_free_table(obj->pages);
|
|
|
|
kfree(obj->pages);
|
2012-06-07 21:38:42 +07:00
|
|
|
}
|
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 16:40:46 +07:00
|
|
|
|
2013-01-15 19:39:35 +07:00
|
|
|
int
|
2012-06-07 21:38:42 +07:00
|
|
|
i915_gem_object_put_pages(struct drm_i915_gem_object *obj)
|
|
|
|
{
|
|
|
|
const struct drm_i915_gem_object_ops *ops = obj->ops;
|
|
|
|
|
2012-09-05 03:02:58 +07:00
|
|
|
if (obj->pages == NULL)
|
2012-06-07 21:38:42 +07:00
|
|
|
return 0;
|
|
|
|
|
2012-09-05 03:02:54 +07:00
|
|
|
if (obj->pages_pin_count)
|
|
|
|
return -EBUSY;
|
|
|
|
|
2013-08-01 07:00:12 +07:00
|
|
|
BUG_ON(i915_gem_obj_bound_any(obj));
|
2013-08-01 07:00:04 +07:00
|
|
|
|
2012-12-03 18:49:00 +07:00
|
|
|
/* ->put_pages might need to allocate memory for the bit17 swizzle
|
|
|
|
* array, hence protect them from being reaped by removing them from gtt
|
|
|
|
* lists early. */
|
2013-06-01 01:28:48 +07:00
|
|
|
list_del(&obj->global_list);
|
2012-12-03 18:49:00 +07:00
|
|
|
|
2012-06-07 21:38:42 +07:00
|
|
|
ops->put_pages(obj);
|
2010-11-09 02:18:58 +07:00
|
|
|
obj->pages = NULL;
|
2012-06-07 21:38:42 +07:00
|
|
|
|
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 16:40:46 +07:00
|
|
|
if (i915_gem_object_is_purgeable(obj))
|
|
|
|
i915_gem_object_truncate(obj);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-10-04 16:33:00 +07:00
|
|
|
static unsigned long
|
drm/i915: Revert shrinker changes from "Track unbound pages"
This partially reverts
commit 6c085a728cf000ac1865d66f8c9b52935558b328
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Aug 20 11:40:46 2012 +0200
drm/i915: Track unbound pages
Closer inspection of that patch revealed a bunch of unrelated changes
in the shrinker:
- The shrinker count is now in pages instead of objects.
- For counting the shrinkable objects the old code only looked at the
inactive list, the new code looks at all bounds objects (including
pinned ones). That is obviously in addition to the new unbound list.
- The shrinker cound is no longer scaled with
sysctl_vfs_cache_pressure. Note though that with the default tuning
value of vfs_cache_pressue = 100 this doesn't affect the shrinker
behaviour.
- When actually shrinking objects, the old code first dropped
purgeable objects, then normal (inactive) objects. Only then did it,
in a last-ditch effort idle the gpu and evict everything. The new
code omits the intermediate step of evicting normal inactive
objects.
Safe for the first change, which seems benign, and the shrinker count
scaling, which is a bit a different story, the endresult of all these
changes is that the shrinker is _much_ more likely to fall back to the
last-ditch resort of idling the gpu and evicting everything. The old
code could only do that if something else evicted lots of objects
meanwhile (since without any other changes the nr_to_scan will be
smaller than the object count).
Reverting the vfs_cache_pressure behaviour itself is a bit bogus: Only
dentry/inode object caches should scale their shrinker counts with
vfs_cache_pressure. Originally I've had that change reverted, too. But
Chris Wilson insisted that it's too bogus and shouldn't again see the
light of day.
Hence revert all these other changes and restore the old shrinker
behaviour, with the minor adjustment that we now first scan the
unbound list, then the inactive list for each object category
(purgeable or normal).
A similar patch has been tested by a few people affected by the gen4/5
hangs which started to appear in 3.7, which some people bisected to
the "drm/i915: Track unbound pages" commit. But just disabling the
unbound logic alone didn't change things at all.
Note that this patch doesn't fix the referenced bugs, it only hides
the underlying bug(s) well enough to restore pre-3.7 behaviour. The
key to achieve that is to massively reduce the likelyhood of going
into a full gpu stall and evicting everything.
v2: Reword commit message a bit, taking Chris Wilson's comment into
account.
v3: On Chris Wilson's insistency, do not reinstate the rather bogus
vfs_cache_pressure change.
Tested-by: Greg KH <gregkh@linuxfoundation.org>
Tested-by: Dave Kleikamp <dave.kleikamp@oracle.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=55984
References: https://bugs.freedesktop.org/show_bug.cgi?id=57122
References: https://bugs.freedesktop.org/show_bug.cgi?id=56916
References: https://bugs.freedesktop.org/show_bug.cgi?id=57136
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-11 00:03:00 +07:00
|
|
|
__i915_gem_shrink(struct drm_i915_private *dev_priv, long target,
|
|
|
|
bool purgeable_only)
|
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 16:40:46 +07:00
|
|
|
{
|
2013-09-04 16:45:50 +07:00
|
|
|
struct list_head still_bound_list;
|
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 16:40:46 +07:00
|
|
|
struct drm_i915_gem_object *obj, *next;
|
2013-10-04 16:33:00 +07:00
|
|
|
unsigned long count = 0;
|
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 16:40:46 +07:00
|
|
|
|
|
|
|
list_for_each_entry_safe(obj, next,
|
|
|
|
&dev_priv->mm.unbound_list,
|
2013-06-01 01:28:48 +07:00
|
|
|
global_list) {
|
drm/i915: Revert shrinker changes from "Track unbound pages"
This partially reverts
commit 6c085a728cf000ac1865d66f8c9b52935558b328
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Aug 20 11:40:46 2012 +0200
drm/i915: Track unbound pages
Closer inspection of that patch revealed a bunch of unrelated changes
in the shrinker:
- The shrinker count is now in pages instead of objects.
- For counting the shrinkable objects the old code only looked at the
inactive list, the new code looks at all bounds objects (including
pinned ones). That is obviously in addition to the new unbound list.
- The shrinker cound is no longer scaled with
sysctl_vfs_cache_pressure. Note though that with the default tuning
value of vfs_cache_pressue = 100 this doesn't affect the shrinker
behaviour.
- When actually shrinking objects, the old code first dropped
purgeable objects, then normal (inactive) objects. Only then did it,
in a last-ditch effort idle the gpu and evict everything. The new
code omits the intermediate step of evicting normal inactive
objects.
Safe for the first change, which seems benign, and the shrinker count
scaling, which is a bit a different story, the endresult of all these
changes is that the shrinker is _much_ more likely to fall back to the
last-ditch resort of idling the gpu and evicting everything. The old
code could only do that if something else evicted lots of objects
meanwhile (since without any other changes the nr_to_scan will be
smaller than the object count).
Reverting the vfs_cache_pressure behaviour itself is a bit bogus: Only
dentry/inode object caches should scale their shrinker counts with
vfs_cache_pressure. Originally I've had that change reverted, too. But
Chris Wilson insisted that it's too bogus and shouldn't again see the
light of day.
Hence revert all these other changes and restore the old shrinker
behaviour, with the minor adjustment that we now first scan the
unbound list, then the inactive list for each object category
(purgeable or normal).
A similar patch has been tested by a few people affected by the gen4/5
hangs which started to appear in 3.7, which some people bisected to
the "drm/i915: Track unbound pages" commit. But just disabling the
unbound logic alone didn't change things at all.
Note that this patch doesn't fix the referenced bugs, it only hides
the underlying bug(s) well enough to restore pre-3.7 behaviour. The
key to achieve that is to massively reduce the likelyhood of going
into a full gpu stall and evicting everything.
v2: Reword commit message a bit, taking Chris Wilson's comment into
account.
v3: On Chris Wilson's insistency, do not reinstate the rather bogus
vfs_cache_pressure change.
Tested-by: Greg KH <gregkh@linuxfoundation.org>
Tested-by: Dave Kleikamp <dave.kleikamp@oracle.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=55984
References: https://bugs.freedesktop.org/show_bug.cgi?id=57122
References: https://bugs.freedesktop.org/show_bug.cgi?id=56916
References: https://bugs.freedesktop.org/show_bug.cgi?id=57136
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-11 00:03:00 +07:00
|
|
|
if ((i915_gem_object_is_purgeable(obj) || !purgeable_only) &&
|
2012-06-07 21:38:42 +07:00
|
|
|
i915_gem_object_put_pages(obj) == 0) {
|
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 16:40:46 +07:00
|
|
|
count += obj->base.size >> PAGE_SHIFT;
|
|
|
|
if (count >= target)
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-09-04 16:45:50 +07:00
|
|
|
/*
|
|
|
|
* As we may completely rewrite the bound list whilst unbinding
|
|
|
|
* (due to retiring requests) we have to strictly process only
|
|
|
|
* one element of the list at the time, and recheck the list
|
|
|
|
* on every iteration.
|
|
|
|
*/
|
|
|
|
INIT_LIST_HEAD(&still_bound_list);
|
|
|
|
while (count < target && !list_empty(&dev_priv->mm.bound_list)) {
|
drm/i915: plumb VM into bind/unbind code
As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).
This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.
> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-01 07:00:10 +07:00
|
|
|
struct i915_vma *vma, *v;
|
2013-08-01 07:00:01 +07:00
|
|
|
|
2013-09-04 16:45:50 +07:00
|
|
|
obj = list_first_entry(&dev_priv->mm.bound_list,
|
|
|
|
typeof(*obj), global_list);
|
|
|
|
list_move_tail(&obj->global_list, &still_bound_list);
|
|
|
|
|
2013-08-01 07:00:01 +07:00
|
|
|
if (!i915_gem_object_is_purgeable(obj) && purgeable_only)
|
|
|
|
continue;
|
|
|
|
|
2013-09-04 16:45:50 +07:00
|
|
|
/*
|
|
|
|
* Hold a reference whilst we unbind this object, as we may
|
|
|
|
* end up waiting for and retiring requests. This might
|
|
|
|
* release the final reference (held by the active list)
|
|
|
|
* and result in the object being freed from under us.
|
|
|
|
* in this object being freed.
|
|
|
|
*
|
|
|
|
* Note 1: Shrinking the bound list is special since only active
|
|
|
|
* (and hence bound objects) can contain such limbo objects, so
|
|
|
|
* we don't need special tricks for shrinking the unbound list.
|
|
|
|
* The only other place where we have to be careful with active
|
|
|
|
* objects suddenly disappearing due to retiring requests is the
|
|
|
|
* eviction code.
|
|
|
|
*
|
|
|
|
* Note 2: Even though the bound list doesn't hold a reference
|
|
|
|
* to the object we can safely grab one here: The final object
|
|
|
|
* unreferencing and the bound_list are both protected by the
|
|
|
|
* dev->struct_mutex and so we won't ever be able to observe an
|
|
|
|
* object on the bound_list with a reference count equals 0.
|
|
|
|
*/
|
|
|
|
drm_gem_object_reference(&obj->base);
|
|
|
|
|
drm/i915: plumb VM into bind/unbind code
As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).
This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.
> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-01 07:00:10 +07:00
|
|
|
list_for_each_entry_safe(vma, v, &obj->vma_list, vma_link)
|
|
|
|
if (i915_vma_unbind(vma))
|
|
|
|
break;
|
2013-08-01 07:00:01 +07:00
|
|
|
|
2013-09-04 16:45:50 +07:00
|
|
|
if (i915_gem_object_put_pages(obj) == 0)
|
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 16:40:46 +07:00
|
|
|
count += obj->base.size >> PAGE_SHIFT;
|
2013-09-04 16:45:50 +07:00
|
|
|
|
|
|
|
drm_gem_object_unreference(&obj->base);
|
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 16:40:46 +07:00
|
|
|
}
|
2013-09-04 16:45:50 +07:00
|
|
|
list_splice(&still_bound_list, &dev_priv->mm.bound_list);
|
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 16:40:46 +07:00
|
|
|
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
2013-10-04 16:33:00 +07:00
|
|
|
static unsigned long
|
drm/i915: Revert shrinker changes from "Track unbound pages"
This partially reverts
commit 6c085a728cf000ac1865d66f8c9b52935558b328
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Aug 20 11:40:46 2012 +0200
drm/i915: Track unbound pages
Closer inspection of that patch revealed a bunch of unrelated changes
in the shrinker:
- The shrinker count is now in pages instead of objects.
- For counting the shrinkable objects the old code only looked at the
inactive list, the new code looks at all bounds objects (including
pinned ones). That is obviously in addition to the new unbound list.
- The shrinker cound is no longer scaled with
sysctl_vfs_cache_pressure. Note though that with the default tuning
value of vfs_cache_pressue = 100 this doesn't affect the shrinker
behaviour.
- When actually shrinking objects, the old code first dropped
purgeable objects, then normal (inactive) objects. Only then did it,
in a last-ditch effort idle the gpu and evict everything. The new
code omits the intermediate step of evicting normal inactive
objects.
Safe for the first change, which seems benign, and the shrinker count
scaling, which is a bit a different story, the endresult of all these
changes is that the shrinker is _much_ more likely to fall back to the
last-ditch resort of idling the gpu and evicting everything. The old
code could only do that if something else evicted lots of objects
meanwhile (since without any other changes the nr_to_scan will be
smaller than the object count).
Reverting the vfs_cache_pressure behaviour itself is a bit bogus: Only
dentry/inode object caches should scale their shrinker counts with
vfs_cache_pressure. Originally I've had that change reverted, too. But
Chris Wilson insisted that it's too bogus and shouldn't again see the
light of day.
Hence revert all these other changes and restore the old shrinker
behaviour, with the minor adjustment that we now first scan the
unbound list, then the inactive list for each object category
(purgeable or normal).
A similar patch has been tested by a few people affected by the gen4/5
hangs which started to appear in 3.7, which some people bisected to
the "drm/i915: Track unbound pages" commit. But just disabling the
unbound logic alone didn't change things at all.
Note that this patch doesn't fix the referenced bugs, it only hides
the underlying bug(s) well enough to restore pre-3.7 behaviour. The
key to achieve that is to massively reduce the likelyhood of going
into a full gpu stall and evicting everything.
v2: Reword commit message a bit, taking Chris Wilson's comment into
account.
v3: On Chris Wilson's insistency, do not reinstate the rather bogus
vfs_cache_pressure change.
Tested-by: Greg KH <gregkh@linuxfoundation.org>
Tested-by: Dave Kleikamp <dave.kleikamp@oracle.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=55984
References: https://bugs.freedesktop.org/show_bug.cgi?id=57122
References: https://bugs.freedesktop.org/show_bug.cgi?id=56916
References: https://bugs.freedesktop.org/show_bug.cgi?id=57136
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-11 00:03:00 +07:00
|
|
|
i915_gem_purge(struct drm_i915_private *dev_priv, long target)
|
|
|
|
{
|
|
|
|
return __i915_gem_shrink(dev_priv, target, true);
|
|
|
|
}
|
|
|
|
|
2013-10-04 16:33:00 +07:00
|
|
|
static unsigned long
|
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 16:40:46 +07:00
|
|
|
i915_gem_shrink_all(struct drm_i915_private *dev_priv)
|
|
|
|
{
|
|
|
|
struct drm_i915_gem_object *obj, *next;
|
drivers: convert shrinkers to new count/scan API
Convert the driver shrinkers to the new API. Most changes are compile
tested only because I either don't have the hardware or it's staging
stuff.
FWIW, the md and android code is pretty good, but the rest of it makes me
want to claw my eyes out. The amount of broken code I just encountered is
mind boggling. I've added comments explaining what is broken, but I fear
that some of the code would be best dealt with by being dragged behind the
bike shed, burying in mud up to it's neck and then run over repeatedly
with a blunt lawn mower.
Special mention goes to the zcache/zcache2 drivers. They can't co-exist
in the build at the same time, they are under different menu options in
menuconfig, they only show up when you've got the right set of mm
subsystem options configured and so even compile testing is an exercise in
pulling teeth. And that doesn't even take into account the horrible,
broken code...
[glommer@openvz.org: fixes for i915, android lowmem, zcache, bcache]
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Glauber Costa <glommer@openvz.org>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Rientjes <rientjes@google.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: J. Bruce Fields <bfields@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-28 07:18:11 +07:00
|
|
|
long freed = 0;
|
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 16:40:46 +07:00
|
|
|
|
|
|
|
i915_gem_evict_everything(dev_priv->dev);
|
|
|
|
|
2013-06-01 01:28:48 +07:00
|
|
|
list_for_each_entry_safe(obj, next, &dev_priv->mm.unbound_list,
|
drivers: convert shrinkers to new count/scan API
Convert the driver shrinkers to the new API. Most changes are compile
tested only because I either don't have the hardware or it's staging
stuff.
FWIW, the md and android code is pretty good, but the rest of it makes me
want to claw my eyes out. The amount of broken code I just encountered is
mind boggling. I've added comments explaining what is broken, but I fear
that some of the code would be best dealt with by being dragged behind the
bike shed, burying in mud up to it's neck and then run over repeatedly
with a blunt lawn mower.
Special mention goes to the zcache/zcache2 drivers. They can't co-exist
in the build at the same time, they are under different menu options in
menuconfig, they only show up when you've got the right set of mm
subsystem options configured and so even compile testing is an exercise in
pulling teeth. And that doesn't even take into account the horrible,
broken code...
[glommer@openvz.org: fixes for i915, android lowmem, zcache, bcache]
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Glauber Costa <glommer@openvz.org>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Rientjes <rientjes@google.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: J. Bruce Fields <bfields@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-28 07:18:11 +07:00
|
|
|
global_list) {
|
2013-10-04 16:33:00 +07:00
|
|
|
if (i915_gem_object_put_pages(obj) == 0)
|
drivers: convert shrinkers to new count/scan API
Convert the driver shrinkers to the new API. Most changes are compile
tested only because I either don't have the hardware or it's staging
stuff.
FWIW, the md and android code is pretty good, but the rest of it makes me
want to claw my eyes out. The amount of broken code I just encountered is
mind boggling. I've added comments explaining what is broken, but I fear
that some of the code would be best dealt with by being dragged behind the
bike shed, burying in mud up to it's neck and then run over repeatedly
with a blunt lawn mower.
Special mention goes to the zcache/zcache2 drivers. They can't co-exist
in the build at the same time, they are under different menu options in
menuconfig, they only show up when you've got the right set of mm
subsystem options configured and so even compile testing is an exercise in
pulling teeth. And that doesn't even take into account the horrible,
broken code...
[glommer@openvz.org: fixes for i915, android lowmem, zcache, bcache]
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Glauber Costa <glommer@openvz.org>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Rientjes <rientjes@google.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: J. Bruce Fields <bfields@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-28 07:18:11 +07:00
|
|
|
freed += obj->base.size >> PAGE_SHIFT;
|
|
|
|
}
|
|
|
|
return freed;
|
2012-08-20 15:23:20 +07:00
|
|
|
}
|
|
|
|
|
2012-06-07 21:38:42 +07:00
|
|
|
static 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 16:40:46 +07:00
|
|
|
i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj)
|
2010-10-28 19:45:36 +07:00
|
|
|
{
|
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 16:40:46 +07:00
|
|
|
struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
|
2010-10-28 19:45:36 +07:00
|
|
|
int page_count, i;
|
|
|
|
struct address_space *mapping;
|
2012-06-01 21:20:22 +07:00
|
|
|
struct sg_table *st;
|
|
|
|
struct scatterlist *sg;
|
2013-02-19 00:28:03 +07:00
|
|
|
struct sg_page_iter sg_iter;
|
2010-10-28 19:45:36 +07:00
|
|
|
struct page *page;
|
2013-02-19 00:28:03 +07:00
|
|
|
unsigned long last_pfn = 0; /* suppress gcc warning */
|
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 16:40:46 +07:00
|
|
|
gfp_t gfp;
|
2010-10-28 19:45:36 +07:00
|
|
|
|
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 16:40:46 +07:00
|
|
|
/* Assert that the object is not currently in any GPU domain. As it
|
|
|
|
* wasn't in the GTT, there shouldn't be any way it could have been in
|
|
|
|
* a GPU cache
|
|
|
|
*/
|
|
|
|
BUG_ON(obj->base.read_domains & I915_GEM_GPU_DOMAINS);
|
|
|
|
BUG_ON(obj->base.write_domain & I915_GEM_GPU_DOMAINS);
|
|
|
|
|
2012-06-01 21:20:22 +07:00
|
|
|
st = kmalloc(sizeof(*st), GFP_KERNEL);
|
|
|
|
if (st == NULL)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
page_count = obj->base.size / PAGE_SIZE;
|
2012-06-01 21:20:22 +07:00
|
|
|
if (sg_alloc_table(st, page_count, GFP_KERNEL)) {
|
|
|
|
kfree(st);
|
2010-10-28 19:45:36 +07:00
|
|
|
return -ENOMEM;
|
2012-06-01 21:20:22 +07:00
|
|
|
}
|
2010-10-28 19:45:36 +07:00
|
|
|
|
2012-06-01 21:20:22 +07:00
|
|
|
/* Get the list of pages out of our struct file. They'll be pinned
|
|
|
|
* at this point until we release them.
|
|
|
|
*
|
|
|
|
* Fail silently without starting the shrinker
|
|
|
|
*/
|
2013-01-24 05:07:38 +07:00
|
|
|
mapping = file_inode(obj->base.filp)->i_mapping;
|
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 16:40:46 +07:00
|
|
|
gfp = mapping_gfp_mask(mapping);
|
Revert "revert "Revert "mm: remove __GFP_NO_KSWAPD""" and associated damage
This reverts commits a50915394f1fc02c2861d3b7ce7014788aa5066e and
d7c3b937bdf45f0b844400b7bf6fd3ed50bac604.
This is a revert of a revert of a revert. In addition, it reverts the
even older i915 change to stop using the __GFP_NO_KSWAPD flag due to the
original commits in linux-next.
It turns out that the original patch really was bogus, and that the
original revert was the correct thing to do after all. We thought we
had fixed the problem, and then reverted the revert, but the problem
really is fundamental: waking up kswapd simply isn't the right thing to
do, and direct reclaim sometimes simply _is_ the right thing to do.
When certain allocations fail, we simply should try some direct reclaim,
and if that fails, fail the allocation. That's the right thing to do
for THP allocations, which can easily fail, and the GPU allocations want
to do that too.
So starting kswapd is sometimes simply wrong, and removing the flag that
said "don't start kswapd" was a mistake. Let's hope we never revisit
this mistake again - and certainly not this many times ;)
Acked-by: Mel Gorman <mgorman@suse.de>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-12-11 01:51:16 +07:00
|
|
|
gfp |= __GFP_NORETRY | __GFP_NOWARN | __GFP_NO_KSWAPD;
|
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 16:40:46 +07:00
|
|
|
gfp &= ~(__GFP_IO | __GFP_WAIT);
|
2013-02-19 00:28:03 +07:00
|
|
|
sg = st->sgl;
|
|
|
|
st->nents = 0;
|
|
|
|
for (i = 0; i < page_count; i++) {
|
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 16:40:46 +07:00
|
|
|
page = shmem_read_mapping_page_gfp(mapping, i, gfp);
|
|
|
|
if (IS_ERR(page)) {
|
|
|
|
i915_gem_purge(dev_priv, page_count);
|
|
|
|
page = shmem_read_mapping_page_gfp(mapping, i, gfp);
|
|
|
|
}
|
|
|
|
if (IS_ERR(page)) {
|
|
|
|
/* We've tried hard to allocate the memory by reaping
|
|
|
|
* our own buffer, now let the real VM do its job and
|
|
|
|
* go down in flames if truly OOM.
|
|
|
|
*/
|
Revert "revert "Revert "mm: remove __GFP_NO_KSWAPD""" and associated damage
This reverts commits a50915394f1fc02c2861d3b7ce7014788aa5066e and
d7c3b937bdf45f0b844400b7bf6fd3ed50bac604.
This is a revert of a revert of a revert. In addition, it reverts the
even older i915 change to stop using the __GFP_NO_KSWAPD flag due to the
original commits in linux-next.
It turns out that the original patch really was bogus, and that the
original revert was the correct thing to do after all. We thought we
had fixed the problem, and then reverted the revert, but the problem
really is fundamental: waking up kswapd simply isn't the right thing to
do, and direct reclaim sometimes simply _is_ the right thing to do.
When certain allocations fail, we simply should try some direct reclaim,
and if that fails, fail the allocation. That's the right thing to do
for THP allocations, which can easily fail, and the GPU allocations want
to do that too.
So starting kswapd is sometimes simply wrong, and removing the flag that
said "don't start kswapd" was a mistake. Let's hope we never revisit
this mistake again - and certainly not this many times ;)
Acked-by: Mel Gorman <mgorman@suse.de>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-12-11 01:51:16 +07:00
|
|
|
gfp &= ~(__GFP_NORETRY | __GFP_NOWARN | __GFP_NO_KSWAPD);
|
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 16:40:46 +07:00
|
|
|
gfp |= __GFP_IO | __GFP_WAIT;
|
|
|
|
|
|
|
|
i915_gem_shrink_all(dev_priv);
|
|
|
|
page = shmem_read_mapping_page_gfp(mapping, i, gfp);
|
|
|
|
if (IS_ERR(page))
|
|
|
|
goto err_pages;
|
|
|
|
|
Revert "revert "Revert "mm: remove __GFP_NO_KSWAPD""" and associated damage
This reverts commits a50915394f1fc02c2861d3b7ce7014788aa5066e and
d7c3b937bdf45f0b844400b7bf6fd3ed50bac604.
This is a revert of a revert of a revert. In addition, it reverts the
even older i915 change to stop using the __GFP_NO_KSWAPD flag due to the
original commits in linux-next.
It turns out that the original patch really was bogus, and that the
original revert was the correct thing to do after all. We thought we
had fixed the problem, and then reverted the revert, but the problem
really is fundamental: waking up kswapd simply isn't the right thing to
do, and direct reclaim sometimes simply _is_ the right thing to do.
When certain allocations fail, we simply should try some direct reclaim,
and if that fails, fail the allocation. That's the right thing to do
for THP allocations, which can easily fail, and the GPU allocations want
to do that too.
So starting kswapd is sometimes simply wrong, and removing the flag that
said "don't start kswapd" was a mistake. Let's hope we never revisit
this mistake again - and certainly not this many times ;)
Acked-by: Mel Gorman <mgorman@suse.de>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-12-11 01:51:16 +07:00
|
|
|
gfp |= __GFP_NORETRY | __GFP_NOWARN | __GFP_NO_KSWAPD;
|
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 16:40:46 +07:00
|
|
|
gfp &= ~(__GFP_IO | __GFP_WAIT);
|
|
|
|
}
|
2013-06-24 22:47:48 +07:00
|
|
|
#ifdef CONFIG_SWIOTLB
|
|
|
|
if (swiotlb_nr_tbl()) {
|
|
|
|
st->nents++;
|
|
|
|
sg_set_page(sg, page, PAGE_SIZE, 0);
|
|
|
|
sg = sg_next(sg);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
#endif
|
2013-02-19 00:28:03 +07:00
|
|
|
if (!i || page_to_pfn(page) != last_pfn + 1) {
|
|
|
|
if (i)
|
|
|
|
sg = sg_next(sg);
|
|
|
|
st->nents++;
|
|
|
|
sg_set_page(sg, page, PAGE_SIZE, 0);
|
|
|
|
} else {
|
|
|
|
sg->length += PAGE_SIZE;
|
|
|
|
}
|
|
|
|
last_pfn = page_to_pfn(page);
|
2013-10-08 03:15:45 +07:00
|
|
|
|
|
|
|
/* Check that the i965g/gm workaround works. */
|
|
|
|
WARN_ON((gfp & __GFP_DMA32) && (last_pfn >= 0x00100000UL));
|
2010-10-28 19:45:36 +07:00
|
|
|
}
|
2013-06-24 22:47:48 +07:00
|
|
|
#ifdef CONFIG_SWIOTLB
|
|
|
|
if (!swiotlb_nr_tbl())
|
|
|
|
#endif
|
|
|
|
sg_mark_end(sg);
|
2012-10-19 21:51:06 +07:00
|
|
|
obj->pages = st;
|
|
|
|
|
2011-09-13 02:30:02 +07:00
|
|
|
if (i915_gem_object_needs_bit17_swizzle(obj))
|
2010-10-28 19:45:36 +07:00
|
|
|
i915_gem_object_do_bit_17_swizzle(obj);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err_pages:
|
2013-02-19 00:28:03 +07:00
|
|
|
sg_mark_end(sg);
|
|
|
|
for_each_sg_page(st->sgl, &sg_iter, st->nents, 0)
|
2013-03-26 20:14:18 +07:00
|
|
|
page_cache_release(sg_page_iter_page(&sg_iter));
|
2012-06-01 21:20:22 +07:00
|
|
|
sg_free_table(st);
|
|
|
|
kfree(st);
|
2010-10-28 19:45:36 +07:00
|
|
|
return PTR_ERR(page);
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
2012-06-07 21:38:42 +07:00
|
|
|
/* Ensure that the associated pages are gathered from the backing storage
|
|
|
|
* and pinned into our object. i915_gem_object_get_pages() may be called
|
|
|
|
* multiple times before they are released by a single call to
|
|
|
|
* i915_gem_object_put_pages() - once the pages are no longer referenced
|
|
|
|
* either as a result of memory pressure (reaping pages under the shrinker)
|
|
|
|
* or as the object is itself released.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
i915_gem_object_get_pages(struct drm_i915_gem_object *obj)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
|
|
|
|
const struct drm_i915_gem_object_ops *ops = obj->ops;
|
|
|
|
int ret;
|
|
|
|
|
2012-09-05 03:02:58 +07:00
|
|
|
if (obj->pages)
|
2012-06-07 21:38:42 +07:00
|
|
|
return 0;
|
|
|
|
|
2013-01-08 17:53:09 +07:00
|
|
|
if (obj->madv != I915_MADV_WILLNEED) {
|
|
|
|
DRM_ERROR("Attempting to obtain a purgeable object\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2012-09-05 03:02:54 +07:00
|
|
|
BUG_ON(obj->pages_pin_count);
|
|
|
|
|
2012-06-07 21:38:42 +07:00
|
|
|
ret = ops->get_pages(obj);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2013-06-01 01:28:48 +07:00
|
|
|
list_add_tail(&obj->global_list, &dev_priv->mm.unbound_list);
|
2012-06-07 21:38:42 +07:00
|
|
|
return 0;
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
2013-09-24 23:57:58 +07:00
|
|
|
static void
|
2010-11-09 02:18:58 +07:00
|
|
|
i915_gem_object_move_to_active(struct drm_i915_gem_object *obj,
|
2012-11-27 23:22:52 +07:00
|
|
|
struct intel_ring_buffer *ring)
|
2008-07-31 02:06:12 +07:00
|
|
|
{
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_device *dev = obj->base.dev;
|
2010-10-19 16:36:51 +07:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2012-11-27 23:22:52 +07:00
|
|
|
u32 seqno = intel_ring_get_seqno(ring);
|
2010-02-12 04:16:02 +07:00
|
|
|
|
2010-05-21 08:08:56 +07:00
|
|
|
BUG_ON(ring == NULL);
|
2013-07-09 15:22:39 +07:00
|
|
|
if (obj->ring != ring && obj->last_write_seqno) {
|
|
|
|
/* Keep the seqno relative to the current ring */
|
|
|
|
obj->last_write_seqno = seqno;
|
|
|
|
}
|
2010-11-09 02:18:58 +07:00
|
|
|
obj->ring = ring;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
|
|
|
/* Add a reference if we're newly entering the active list. */
|
2010-11-09 02:18:58 +07:00
|
|
|
if (!obj->active) {
|
|
|
|
drm_gem_object_reference(&obj->base);
|
|
|
|
obj->active = 1;
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
drm/i915: allow lazy emitting of requests
Sometimes (like when flushing in preparation of batchbuffer execution)
we know that we'll emit a request but haven't yet done so. Allow this
case by simply taking the next seqno by default. Ensure that a request
is eventually emitted before waiting for an request by issuing it
in i915_wait_request iff this is not yet done.
Also replace one open-coded version of i915_gem_object_wait_rendering,
to prevent future code-diversion.
Chris Wilson asked me to explain and clarify what this patch does and why.
Here it goes:
Old way of moving objects onto the active list and associating them with a
reques:
1. i915_add_request + store the returned seqno somewhere
2. i915_gem_object_move_to_active (with the stored seqno as parameter)
For the current users, this is all fine. But I'd like to associate objects
(and fence regs) with the batchbuffer request deep down in the execbuf
call-chain. I thought about three ways of implementing this.
a) Don't care, just emit request when we need a new seqno. When heavily
pipelining fence reg changes, this would have caused tons of superflous
request (and corresponding irqs).
b) Thread all changed fences, objects, whatever through the execbuf-maze,
so that when we emit a request, we can store the new seqno at all the right
places.
c) Kill that seqno-threading-around business by simply storing the next
seqno, i.e. allow 2. to be done before 1. in the above sequence.
I've decided to implement c) (in this patch). The following patches are
just fall-out that resulted from this small conceptual change.
* We can handle the flushing list processing where we actually emit a flush
(i915_gem_flush and i915_retire_commands) instead of in i915_add_request.
The code makes IMHO more sense this way (and i915_add_request looses the
flush_domains parameter, obviously).
* We can avoid emitting unnecessary requests. IMHO there's no point in
emitting more than one request per batchbuffer (with or without an
corresponding irq).
* By enforcing 2. before 1. ordering in the above sequence the seqno
argument of i915_gem_object_move_to_active is redundant and can be
dropped.
v2: Now i915_wait_request issues request if it is not yet emitted.
Also introduce i915_gem_next_request_seqno(dev) just in case we ever
need to do some prep work before using a new seqno.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[ickle: Keep i915_gem_object_set_to_display_plane() uninterruptible.]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-02-12 04:13:59 +07:00
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
list_move_tail(&obj->ring_list, &ring->active_list);
|
2010-11-12 20:53:37 +07:00
|
|
|
|
2012-07-20 18:41:01 +07:00
|
|
|
obj->last_read_seqno = seqno;
|
2010-11-12 20:53:37 +07:00
|
|
|
|
2012-03-21 17:48:18 +07:00
|
|
|
if (obj->fenced_gpu_access) {
|
2010-11-12 20:53:37 +07:00
|
|
|
obj->last_fenced_seqno = seqno;
|
|
|
|
|
2012-03-21 17:48:18 +07:00
|
|
|
/* Bump MRU to take account of the delayed flush */
|
|
|
|
if (obj->fence_reg != I915_FENCE_REG_NONE) {
|
|
|
|
struct drm_i915_fence_reg *reg;
|
|
|
|
|
|
|
|
reg = &dev_priv->fence_regs[obj->fence_reg];
|
|
|
|
list_move_tail(®->lru_list,
|
|
|
|
&dev_priv->mm.fence_list);
|
|
|
|
}
|
2010-11-12 20:53:37 +07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-09-24 23:57:58 +07:00
|
|
|
void i915_vma_move_to_active(struct i915_vma *vma,
|
|
|
|
struct intel_ring_buffer *ring)
|
|
|
|
{
|
|
|
|
list_move_tail(&vma->mm_list, &vma->vm->active_list);
|
|
|
|
return i915_gem_object_move_to_active(vma->obj, ring);
|
|
|
|
}
|
|
|
|
|
2010-11-12 20:53:37 +07:00
|
|
|
static void
|
|
|
|
i915_gem_object_move_to_inactive(struct drm_i915_gem_object *obj)
|
2008-11-07 07:00:31 +07:00
|
|
|
{
|
2013-08-01 07:00:14 +07:00
|
|
|
struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
|
|
|
|
struct i915_address_space *ggtt_vm = &dev_priv->gtt.base;
|
|
|
|
struct i915_vma *vma = i915_gem_obj_to_vma(obj, ggtt_vm);
|
2008-11-07 07:00:31 +07:00
|
|
|
|
2012-07-20 18:41:02 +07:00
|
|
|
BUG_ON(obj->base.write_domain & ~I915_GEM_GPU_DOMAINS);
|
2010-11-09 02:18:58 +07:00
|
|
|
BUG_ON(!obj->active);
|
2010-11-12 20:53:37 +07:00
|
|
|
|
2013-08-01 07:00:14 +07:00
|
|
|
list_move_tail(&vma->mm_list, &ggtt_vm->inactive_list);
|
2010-11-12 20:53:37 +07:00
|
|
|
|
2012-07-20 18:41:02 +07:00
|
|
|
list_del_init(&obj->ring_list);
|
2010-11-12 20:53:37 +07:00
|
|
|
obj->ring = NULL;
|
|
|
|
|
2012-07-20 18:41:02 +07:00
|
|
|
obj->last_read_seqno = 0;
|
|
|
|
obj->last_write_seqno = 0;
|
|
|
|
obj->base.write_domain = 0;
|
|
|
|
|
|
|
|
obj->last_fenced_seqno = 0;
|
2010-11-12 20:53:37 +07:00
|
|
|
obj->fenced_gpu_access = false;
|
|
|
|
|
|
|
|
obj->active = 0;
|
|
|
|
drm_gem_object_unreference(&obj->base);
|
|
|
|
|
|
|
|
WARN_ON(i915_verify_lists(dev));
|
2008-11-07 07:00:31 +07:00
|
|
|
}
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2012-11-27 23:22:52 +07:00
|
|
|
static int
|
2012-12-19 16:13:08 +07:00
|
|
|
i915_gem_init_seqno(struct drm_device *dev, u32 seqno)
|
2012-01-25 22:32:49 +07:00
|
|
|
{
|
2012-11-27 23:22:52 +07:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
|
|
|
struct intel_ring_buffer *ring;
|
|
|
|
int ret, i, j;
|
2012-01-25 22:32:49 +07:00
|
|
|
|
2012-12-10 18:56:17 +07:00
|
|
|
/* Carefully retire all requests without writing to the rings */
|
2012-11-27 23:22:52 +07:00
|
|
|
for_each_ring(ring, dev_priv, i) {
|
2012-12-10 18:56:17 +07:00
|
|
|
ret = intel_ring_idle(ring);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2012-11-27 23:22:52 +07:00
|
|
|
}
|
|
|
|
i915_gem_retire_requests(dev);
|
2012-12-10 18:56:17 +07:00
|
|
|
|
|
|
|
/* Finally reset hw state */
|
2012-11-27 23:22:52 +07:00
|
|
|
for_each_ring(ring, dev_priv, i) {
|
2012-12-19 16:13:08 +07:00
|
|
|
intel_ring_init_seqno(ring, seqno);
|
2012-12-04 20:12:04 +07:00
|
|
|
|
2012-11-27 23:22:52 +07:00
|
|
|
for (j = 0; j < ARRAY_SIZE(ring->sync_seqno); j++)
|
|
|
|
ring->sync_seqno[j] = 0;
|
|
|
|
}
|
2012-01-25 22:32:49 +07:00
|
|
|
|
2012-11-27 23:22:52 +07:00
|
|
|
return 0;
|
2012-01-25 22:32:49 +07:00
|
|
|
}
|
|
|
|
|
2012-12-19 16:13:08 +07:00
|
|
|
int i915_gem_set_seqno(struct drm_device *dev, u32 seqno)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (seqno == 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* HWS page needs to be set less than what we
|
|
|
|
* will inject to ring
|
|
|
|
*/
|
|
|
|
ret = i915_gem_init_seqno(dev, seqno - 1);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
/* Carefully set the last_seqno value so that wrap
|
|
|
|
* detection still works
|
|
|
|
*/
|
|
|
|
dev_priv->next_seqno = seqno;
|
|
|
|
dev_priv->last_seqno = seqno - 1;
|
|
|
|
if (dev_priv->last_seqno == 0)
|
|
|
|
dev_priv->last_seqno--;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-11-27 23:22:52 +07:00
|
|
|
int
|
|
|
|
i915_gem_get_seqno(struct drm_device *dev, u32 *seqno)
|
2012-01-25 22:32:49 +07:00
|
|
|
{
|
2012-11-27 23:22:52 +07:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
|
|
|
|
|
|
|
/* reserve 0 for non-seqno */
|
|
|
|
if (dev_priv->next_seqno == 0) {
|
2012-12-19 16:13:08 +07:00
|
|
|
int ret = i915_gem_init_seqno(dev, 0);
|
2012-11-27 23:22:52 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
2012-01-25 22:32:49 +07:00
|
|
|
|
2012-11-27 23:22:52 +07:00
|
|
|
dev_priv->next_seqno = 1;
|
|
|
|
}
|
2012-01-25 22:32:49 +07:00
|
|
|
|
2012-12-10 20:41:48 +07:00
|
|
|
*seqno = dev_priv->last_seqno = dev_priv->next_seqno++;
|
2012-11-27 23:22:52 +07:00
|
|
|
return 0;
|
2012-01-25 22:32:49 +07:00
|
|
|
}
|
|
|
|
|
2013-06-12 16:35:30 +07:00
|
|
|
int __i915_add_request(struct intel_ring_buffer *ring,
|
|
|
|
struct drm_file *file,
|
2013-06-12 19:01:39 +07:00
|
|
|
struct drm_i915_gem_object *obj,
|
2013-06-12 16:35:30 +07:00
|
|
|
u32 *out_seqno)
|
2008-07-31 02:06:12 +07:00
|
|
|
{
|
2011-02-03 18:57:46 +07:00
|
|
|
drm_i915_private_t *dev_priv = ring->dev->dev_private;
|
2012-09-26 19:47:30 +07:00
|
|
|
struct drm_i915_gem_request *request;
|
2013-06-12 19:01:39 +07:00
|
|
|
u32 request_ring_position, request_start;
|
2008-07-31 02:06:12 +07:00
|
|
|
int was_empty;
|
2010-10-27 22:11:02 +07:00
|
|
|
int ret;
|
|
|
|
|
2013-06-12 19:01:39 +07:00
|
|
|
request_start = intel_ring_get_tail(ring);
|
2012-06-14 01:45:19 +07:00
|
|
|
/*
|
|
|
|
* Emit any outstanding flushes - execbuf can fail to emit the flush
|
|
|
|
* after having emitted the batchbuffer command. Hence we need to fix
|
|
|
|
* things up similar to emitting the lazy request. The difference here
|
|
|
|
* is that the flush _must_ happen before the next request, no matter
|
|
|
|
* what.
|
|
|
|
*/
|
2012-07-20 18:41:08 +07:00
|
|
|
ret = intel_ring_flush_all_caches(ring);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2012-06-14 01:45:19 +07:00
|
|
|
|
2013-09-04 16:45:52 +07:00
|
|
|
request = ring->preallocated_lazy_request;
|
|
|
|
if (WARN_ON(request == NULL))
|
2012-09-26 19:47:30 +07:00
|
|
|
return -ENOMEM;
|
2012-06-14 01:45:19 +07:00
|
|
|
|
2012-02-15 18:25:36 +07:00
|
|
|
/* Record the position of the start of the request so that
|
|
|
|
* should we detect the updated seqno part-way through the
|
|
|
|
* GPU processing the request, we never over-estimate the
|
|
|
|
* position of the head.
|
|
|
|
*/
|
|
|
|
request_ring_position = intel_ring_get_tail(ring);
|
|
|
|
|
2012-11-27 23:22:52 +07:00
|
|
|
ret = ring->add_request(ring);
|
2013-09-04 16:45:52 +07:00
|
|
|
if (ret)
|
2012-07-20 18:40:59 +07:00
|
|
|
return ret;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2012-11-27 23:22:52 +07:00
|
|
|
request->seqno = intel_ring_get_seqno(ring);
|
2010-05-21 08:08:56 +07:00
|
|
|
request->ring = ring;
|
2013-06-12 19:01:39 +07:00
|
|
|
request->head = request_start;
|
2012-02-15 18:25:36 +07:00
|
|
|
request->tail = request_ring_position;
|
2013-06-12 19:01:39 +07:00
|
|
|
|
|
|
|
/* Whilst this request exists, batch_obj will be on the
|
|
|
|
* active_list, and so will hold the active reference. Only when this
|
|
|
|
* request is retired will the the batch_obj be moved onto the
|
|
|
|
* inactive_list and lose its active reference. Hence we do not need
|
|
|
|
* to explicitly hold another reference here.
|
|
|
|
*/
|
2013-08-27 05:50:54 +07:00
|
|
|
request->batch_obj = obj;
|
2013-05-02 20:48:08 +07:00
|
|
|
|
2013-08-27 05:50:54 +07:00
|
|
|
/* Hold a reference to the current context so that we can inspect
|
|
|
|
* it later in case a hangcheck error event fires.
|
|
|
|
*/
|
|
|
|
request->ctx = ring->last_context;
|
2013-05-02 20:48:08 +07:00
|
|
|
if (request->ctx)
|
|
|
|
i915_gem_context_reference(request->ctx);
|
|
|
|
|
2008-07-31 02:06:12 +07:00
|
|
|
request->emitted_jiffies = jiffies;
|
2010-05-21 08:08:56 +07:00
|
|
|
was_empty = list_empty(&ring->request_list);
|
|
|
|
list_add_tail(&request->list, &ring->request_list);
|
2012-07-20 18:40:59 +07:00
|
|
|
request->file_priv = NULL;
|
2010-05-21 08:08:56 +07:00
|
|
|
|
2011-02-03 18:57:46 +07:00
|
|
|
if (file) {
|
|
|
|
struct drm_i915_file_private *file_priv = file->driver_priv;
|
|
|
|
|
2010-09-26 17:03:27 +07:00
|
|
|
spin_lock(&file_priv->mm.lock);
|
2010-09-24 22:02:42 +07:00
|
|
|
request->file_priv = file_priv;
|
2009-06-03 14:27:35 +07:00
|
|
|
list_add_tail(&request->client_list,
|
2010-09-24 22:02:42 +07:00
|
|
|
&file_priv->mm.request_list);
|
2010-09-26 17:03:27 +07:00
|
|
|
spin_unlock(&file_priv->mm.lock);
|
2009-06-03 14:27:35 +07:00
|
|
|
}
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2012-11-27 23:22:52 +07:00
|
|
|
trace_i915_gem_request_add(ring, request->seqno);
|
2013-09-04 16:45:51 +07:00
|
|
|
ring->outstanding_lazy_seqno = 0;
|
2013-09-04 16:45:52 +07:00
|
|
|
ring->preallocated_lazy_request = NULL;
|
2011-02-03 18:57:46 +07:00
|
|
|
|
2013-07-09 21:51:37 +07:00
|
|
|
if (!dev_priv->ums.mm_suspended) {
|
2013-07-03 21:22:08 +07:00
|
|
|
i915_queue_hangcheck(ring->dev);
|
|
|
|
|
2012-07-21 18:31:41 +07:00
|
|
|
if (was_empty) {
|
drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-25 23:34:56 +07:00
|
|
|
cancel_delayed_work_sync(&dev_priv->mm.idle_work);
|
2010-09-14 05:44:34 +07:00
|
|
|
queue_delayed_work(dev_priv->wq,
|
2012-10-05 23:02:57 +07:00
|
|
|
&dev_priv->mm.retire_work,
|
|
|
|
round_jiffies_up_relative(HZ));
|
2012-07-21 18:31:41 +07:00
|
|
|
intel_mark_busy(dev_priv->dev);
|
|
|
|
}
|
2009-09-15 04:48:44 +07:00
|
|
|
}
|
2012-06-14 01:45:19 +07:00
|
|
|
|
2012-09-26 19:47:30 +07:00
|
|
|
if (out_seqno)
|
2012-11-27 23:22:52 +07:00
|
|
|
*out_seqno = request->seqno;
|
2010-10-27 22:11:02 +07:00
|
|
|
return 0;
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
2010-09-24 22:02:42 +07:00
|
|
|
static inline void
|
|
|
|
i915_gem_request_remove_from_client(struct drm_i915_gem_request *request)
|
2008-07-31 02:06:12 +07:00
|
|
|
{
|
2010-09-26 17:03:27 +07:00
|
|
|
struct drm_i915_file_private *file_priv = request->file_priv;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2010-09-26 17:03:27 +07:00
|
|
|
if (!file_priv)
|
|
|
|
return;
|
2009-08-25 17:15:50 +07:00
|
|
|
|
2010-09-26 17:03:27 +07:00
|
|
|
spin_lock(&file_priv->mm.lock);
|
drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-25 23:34:56 +07:00
|
|
|
list_del(&request->client_list);
|
|
|
|
request->file_priv = NULL;
|
2010-09-26 17:03:27 +07:00
|
|
|
spin_unlock(&file_priv->mm.lock);
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
2013-08-01 07:00:05 +07:00
|
|
|
static bool i915_head_inside_object(u32 acthd, struct drm_i915_gem_object *obj,
|
|
|
|
struct i915_address_space *vm)
|
2013-06-12 19:13:20 +07:00
|
|
|
{
|
2013-08-01 07:00:05 +07:00
|
|
|
if (acthd >= i915_gem_obj_offset(obj, vm) &&
|
|
|
|
acthd < i915_gem_obj_offset(obj, vm) + obj->base.size)
|
2013-06-12 19:13:20 +07:00
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool i915_head_inside_request(const u32 acthd_unmasked,
|
|
|
|
const u32 request_start,
|
|
|
|
const u32 request_end)
|
|
|
|
{
|
|
|
|
const u32 acthd = acthd_unmasked & HEAD_ADDR;
|
|
|
|
|
|
|
|
if (request_start < request_end) {
|
|
|
|
if (acthd >= request_start && acthd < request_end)
|
|
|
|
return true;
|
|
|
|
} else if (request_start > request_end) {
|
|
|
|
if (acthd >= request_start || acthd < request_end)
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2013-08-01 07:00:05 +07:00
|
|
|
static struct i915_address_space *
|
|
|
|
request_to_vm(struct drm_i915_gem_request *request)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = request->ring->dev->dev_private;
|
|
|
|
struct i915_address_space *vm;
|
|
|
|
|
|
|
|
vm = &dev_priv->gtt.base;
|
|
|
|
|
|
|
|
return vm;
|
|
|
|
}
|
|
|
|
|
2013-06-12 19:13:20 +07:00
|
|
|
static bool i915_request_guilty(struct drm_i915_gem_request *request,
|
|
|
|
const u32 acthd, bool *inside)
|
|
|
|
{
|
|
|
|
/* There is a possibility that unmasked head address
|
|
|
|
* pointing inside the ring, matches the batch_obj address range.
|
|
|
|
* However this is extremely unlikely.
|
|
|
|
*/
|
|
|
|
if (request->batch_obj) {
|
2013-08-01 07:00:05 +07:00
|
|
|
if (i915_head_inside_object(acthd, request->batch_obj,
|
|
|
|
request_to_vm(request))) {
|
2013-06-12 19:13:20 +07:00
|
|
|
*inside = true;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (i915_head_inside_request(acthd, request->head, request->tail)) {
|
|
|
|
*inside = false;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2013-08-30 20:19:28 +07:00
|
|
|
static bool i915_context_is_banned(const struct i915_ctx_hang_stats *hs)
|
|
|
|
{
|
|
|
|
const unsigned long elapsed = get_seconds() - hs->guilty_ts;
|
|
|
|
|
|
|
|
if (hs->banned)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
if (elapsed <= DRM_I915_CTX_BAN_PERIOD) {
|
|
|
|
DRM_ERROR("context hanging too fast, declaring banned!\n");
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2013-06-12 19:13:20 +07:00
|
|
|
static void i915_set_reset_status(struct intel_ring_buffer *ring,
|
|
|
|
struct drm_i915_gem_request *request,
|
|
|
|
u32 acthd)
|
|
|
|
{
|
|
|
|
struct i915_ctx_hang_stats *hs = NULL;
|
|
|
|
bool inside, guilty;
|
2013-08-01 07:00:05 +07:00
|
|
|
unsigned long offset = 0;
|
2013-06-12 19:13:20 +07:00
|
|
|
|
|
|
|
/* Innocent until proven guilty */
|
|
|
|
guilty = false;
|
|
|
|
|
2013-08-01 07:00:05 +07:00
|
|
|
if (request->batch_obj)
|
|
|
|
offset = i915_gem_obj_offset(request->batch_obj,
|
|
|
|
request_to_vm(request));
|
|
|
|
|
2013-08-11 16:44:01 +07:00
|
|
|
if (ring->hangcheck.action != HANGCHECK_WAIT &&
|
2013-06-12 19:13:20 +07:00
|
|
|
i915_request_guilty(request, acthd, &inside)) {
|
2013-07-06 04:41:04 +07:00
|
|
|
DRM_ERROR("%s hung %s bo (0x%lx ctx %d) at 0x%x\n",
|
2013-06-12 19:13:20 +07:00
|
|
|
ring->name,
|
|
|
|
inside ? "inside" : "flushing",
|
2013-08-01 07:00:05 +07:00
|
|
|
offset,
|
2013-06-12 19:13:20 +07:00
|
|
|
request->ctx ? request->ctx->id : 0,
|
|
|
|
acthd);
|
|
|
|
|
|
|
|
guilty = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If contexts are disabled or this is the default context, use
|
|
|
|
* file_priv->reset_state
|
|
|
|
*/
|
|
|
|
if (request->ctx && request->ctx->id != DEFAULT_CONTEXT_ID)
|
|
|
|
hs = &request->ctx->hang_stats;
|
|
|
|
else if (request->file_priv)
|
|
|
|
hs = &request->file_priv->hang_stats;
|
|
|
|
|
|
|
|
if (hs) {
|
2013-08-30 20:19:28 +07:00
|
|
|
if (guilty) {
|
|
|
|
hs->banned = i915_context_is_banned(hs);
|
2013-06-12 19:13:20 +07:00
|
|
|
hs->batch_active++;
|
2013-08-30 20:19:28 +07:00
|
|
|
hs->guilty_ts = get_seconds();
|
|
|
|
} else {
|
2013-06-12 19:13:20 +07:00
|
|
|
hs->batch_pending++;
|
2013-08-30 20:19:28 +07:00
|
|
|
}
|
2013-06-12 19:13:20 +07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-05-02 20:48:08 +07:00
|
|
|
static void i915_gem_free_request(struct drm_i915_gem_request *request)
|
|
|
|
{
|
|
|
|
list_del(&request->list);
|
|
|
|
i915_gem_request_remove_from_client(request);
|
|
|
|
|
|
|
|
if (request->ctx)
|
|
|
|
i915_gem_context_unreference(request->ctx);
|
|
|
|
|
|
|
|
kfree(request);
|
|
|
|
}
|
|
|
|
|
2010-09-22 16:31:52 +07:00
|
|
|
static void i915_gem_reset_ring_lists(struct drm_i915_private *dev_priv,
|
|
|
|
struct intel_ring_buffer *ring)
|
2010-09-19 18:21:28 +07:00
|
|
|
{
|
2013-06-12 19:13:20 +07:00
|
|
|
u32 completed_seqno;
|
|
|
|
u32 acthd;
|
|
|
|
|
|
|
|
acthd = intel_ring_get_active_head(ring);
|
|
|
|
completed_seqno = ring->get_seqno(ring, false);
|
|
|
|
|
2010-09-22 16:31:52 +07:00
|
|
|
while (!list_empty(&ring->request_list)) {
|
|
|
|
struct drm_i915_gem_request *request;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2010-09-22 16:31:52 +07:00
|
|
|
request = list_first_entry(&ring->request_list,
|
|
|
|
struct drm_i915_gem_request,
|
|
|
|
list);
|
2008-11-13 01:03:55 +07:00
|
|
|
|
2013-06-12 19:13:20 +07:00
|
|
|
if (request->seqno > completed_seqno)
|
|
|
|
i915_set_reset_status(ring, request, acthd);
|
|
|
|
|
2013-05-02 20:48:08 +07:00
|
|
|
i915_gem_free_request(request);
|
2010-09-22 16:31:52 +07:00
|
|
|
}
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2010-09-22 16:31:52 +07:00
|
|
|
while (!list_empty(&ring->active_list)) {
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_i915_gem_object *obj;
|
2010-09-19 18:21:28 +07:00
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
obj = list_first_entry(&ring->active_list,
|
|
|
|
struct drm_i915_gem_object,
|
|
|
|
ring_list);
|
2010-09-19 18:21:28 +07:00
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
i915_gem_object_move_to_inactive(obj);
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-06-12 16:15:12 +07:00
|
|
|
void i915_gem_restore_fences(struct drm_device *dev)
|
2010-11-22 18:50:11 +07:00
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
|
|
|
int i;
|
|
|
|
|
2011-10-10 02:52:02 +07:00
|
|
|
for (i = 0; i < dev_priv->num_fence_regs; i++) {
|
2010-11-22 18:50:11 +07:00
|
|
|
struct drm_i915_fence_reg *reg = &dev_priv->fence_regs[i];
|
2010-11-28 00:38:29 +07:00
|
|
|
|
2013-07-17 19:51:28 +07:00
|
|
|
/*
|
|
|
|
* Commit delayed tiling changes if we have an object still
|
|
|
|
* attached to the fence, otherwise just clear the fence.
|
|
|
|
*/
|
|
|
|
if (reg->obj) {
|
|
|
|
i915_gem_object_update_fence(reg->obj, reg,
|
|
|
|
reg->obj->tiling_mode);
|
|
|
|
} else {
|
|
|
|
i915_gem_write_fence(dev, i, NULL);
|
|
|
|
}
|
2010-11-22 18:50:11 +07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-09-30 22:53:18 +07:00
|
|
|
void i915_gem_reset(struct drm_device *dev)
|
2008-07-31 02:06:12 +07:00
|
|
|
{
|
2010-09-19 18:31:36 +07:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2012-05-11 20:29:30 +07:00
|
|
|
struct intel_ring_buffer *ring;
|
2010-12-04 18:30:53 +07:00
|
|
|
int i;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2012-05-11 20:29:30 +07:00
|
|
|
for_each_ring(ring, dev_priv, i)
|
|
|
|
i915_gem_reset_ring_lists(dev_priv, ring);
|
2010-09-22 16:31:52 +07:00
|
|
|
|
2013-10-15 00:01:36 +07:00
|
|
|
i915_gem_cleanup_ringbuffer(dev);
|
|
|
|
|
2013-06-12 16:15:12 +07:00
|
|
|
i915_gem_restore_fences(dev);
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* This function clears the request list as sequence numbers are passed.
|
|
|
|
*/
|
2012-02-15 18:25:36 +07:00
|
|
|
void
|
2011-02-03 18:57:46 +07:00
|
|
|
i915_gem_retire_requests_ring(struct intel_ring_buffer *ring)
|
2008-07-31 02:06:12 +07:00
|
|
|
{
|
|
|
|
uint32_t seqno;
|
|
|
|
|
2011-02-03 18:57:46 +07:00
|
|
|
if (list_empty(&ring->request_list))
|
2009-02-23 21:07:57 +07:00
|
|
|
return;
|
|
|
|
|
2011-02-03 18:57:46 +07:00
|
|
|
WARN_ON(i915_verify_lists(ring->dev));
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2012-08-09 16:58:30 +07:00
|
|
|
seqno = ring->get_seqno(ring, true);
|
2010-12-04 18:30:53 +07:00
|
|
|
|
2010-05-21 08:08:56 +07:00
|
|
|
while (!list_empty(&ring->request_list)) {
|
2008-07-31 02:06:12 +07:00
|
|
|
struct drm_i915_gem_request *request;
|
|
|
|
|
2010-05-21 08:08:56 +07:00
|
|
|
request = list_first_entry(&ring->request_list,
|
2008-07-31 02:06:12 +07:00
|
|
|
struct drm_i915_gem_request,
|
|
|
|
list);
|
|
|
|
|
2010-09-22 16:31:52 +07:00
|
|
|
if (!i915_seqno_passed(seqno, request->seqno))
|
2010-09-18 07:38:04 +07:00
|
|
|
break;
|
|
|
|
|
2011-02-03 18:57:46 +07:00
|
|
|
trace_i915_gem_request_retire(ring, request->seqno);
|
2012-02-15 18:25:36 +07:00
|
|
|
/* We know the GPU must have read the request to have
|
|
|
|
* sent us the seqno + interrupt, so use the position
|
|
|
|
* of tail of the request to update the last known position
|
|
|
|
* of the GPU head.
|
|
|
|
*/
|
|
|
|
ring->last_retired_head = request->tail;
|
2010-09-18 07:38:04 +07:00
|
|
|
|
2013-05-02 20:48:08 +07:00
|
|
|
i915_gem_free_request(request);
|
2010-09-18 07:38:04 +07:00
|
|
|
}
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2010-09-18 07:38:04 +07:00
|
|
|
/* Move any buffers on the active list that are no longer referenced
|
|
|
|
* by the ringbuffer to the flushing/inactive lists as appropriate.
|
|
|
|
*/
|
|
|
|
while (!list_empty(&ring->active_list)) {
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_i915_gem_object *obj;
|
2010-09-18 07:38:04 +07:00
|
|
|
|
2011-08-17 02:34:10 +07:00
|
|
|
obj = list_first_entry(&ring->active_list,
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_i915_gem_object,
|
|
|
|
ring_list);
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2012-07-20 18:41:01 +07:00
|
|
|
if (!i915_seqno_passed(seqno, obj->last_read_seqno))
|
2008-07-31 02:06:12 +07:00
|
|
|
break;
|
2010-09-18 07:38:04 +07:00
|
|
|
|
2012-07-20 18:41:02 +07:00
|
|
|
i915_gem_object_move_to_inactive(obj);
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
2009-09-24 11:26:06 +07:00
|
|
|
|
2011-02-03 18:57:46 +07:00
|
|
|
if (unlikely(ring->trace_irq_seqno &&
|
|
|
|
i915_seqno_passed(seqno, ring->trace_irq_seqno))) {
|
2010-12-04 18:30:53 +07:00
|
|
|
ring->irq_put(ring);
|
2011-02-03 18:57:46 +07:00
|
|
|
ring->trace_irq_seqno = 0;
|
2009-09-24 11:26:06 +07:00
|
|
|
}
|
2010-09-29 22:10:57 +07:00
|
|
|
|
2011-02-03 18:57:46 +07:00
|
|
|
WARN_ON(i915_verify_lists(ring->dev));
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-25 23:34:56 +07:00
|
|
|
bool
|
2010-07-24 05:18:49 +07:00
|
|
|
i915_gem_retire_requests(struct drm_device *dev)
|
|
|
|
{
|
|
|
|
drm_i915_private_t *dev_priv = dev->dev_private;
|
2012-05-11 20:29:30 +07:00
|
|
|
struct intel_ring_buffer *ring;
|
drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-25 23:34:56 +07:00
|
|
|
bool idle = true;
|
2010-12-04 18:30:53 +07:00
|
|
|
int i;
|
2010-07-24 05:18:49 +07:00
|
|
|
|
drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-25 23:34:56 +07:00
|
|
|
for_each_ring(ring, dev_priv, i) {
|
2012-05-11 20:29:30 +07:00
|
|
|
i915_gem_retire_requests_ring(ring);
|
drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-25 23:34:56 +07:00
|
|
|
idle &= list_empty(&ring->request_list);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (idle)
|
|
|
|
mod_delayed_work(dev_priv->wq,
|
|
|
|
&dev_priv->mm.idle_work,
|
|
|
|
msecs_to_jiffies(100));
|
|
|
|
|
|
|
|
return idle;
|
2010-07-24 05:18:49 +07:00
|
|
|
}
|
|
|
|
|
2010-08-21 05:25:16 +07:00
|
|
|
static void
|
2008-07-31 02:06:12 +07:00
|
|
|
i915_gem_retire_work_handler(struct work_struct *work)
|
|
|
|
{
|
drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-25 23:34:56 +07:00
|
|
|
struct drm_i915_private *dev_priv =
|
|
|
|
container_of(work, typeof(*dev_priv), mm.retire_work.work);
|
|
|
|
struct drm_device *dev = dev_priv->dev;
|
2011-01-10 04:05:44 +07:00
|
|
|
bool idle;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2010-09-29 18:26:37 +07:00
|
|
|
/* Come back later if the device is busy... */
|
drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-25 23:34:56 +07:00
|
|
|
idle = false;
|
|
|
|
if (mutex_trylock(&dev->struct_mutex)) {
|
|
|
|
idle = i915_gem_retire_requests(dev);
|
|
|
|
mutex_unlock(&dev->struct_mutex);
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-25 23:34:56 +07:00
|
|
|
if (!idle)
|
2012-10-05 23:02:57 +07:00
|
|
|
queue_delayed_work(dev_priv->wq, &dev_priv->mm.retire_work,
|
|
|
|
round_jiffies_up_relative(HZ));
|
drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-25 23:34:56 +07:00
|
|
|
}
|
2011-01-10 04:05:44 +07:00
|
|
|
|
drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-25 23:34:56 +07:00
|
|
|
static void
|
|
|
|
i915_gem_idle_work_handler(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv =
|
|
|
|
container_of(work, typeof(*dev_priv), mm.idle_work.work);
|
|
|
|
|
|
|
|
intel_mark_idle(dev_priv->dev);
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
2012-06-01 20:21:23 +07:00
|
|
|
/**
|
|
|
|
* Ensures that an object will eventually get non-busy by flushing any required
|
|
|
|
* write domains, emitting any outstanding lazy request and retiring and
|
|
|
|
* completed requests.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
i915_gem_object_flush_active(struct drm_i915_gem_object *obj)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (obj->active) {
|
2012-07-20 18:41:01 +07:00
|
|
|
ret = i915_gem_check_olr(obj->ring, obj->last_read_seqno);
|
2012-06-01 20:21:23 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
i915_gem_retire_requests_ring(obj->ring);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-05-25 05:03:10 +07:00
|
|
|
/**
|
|
|
|
* i915_gem_wait_ioctl - implements DRM_IOCTL_I915_GEM_WAIT
|
|
|
|
* @DRM_IOCTL_ARGS: standard ioctl arguments
|
|
|
|
*
|
|
|
|
* Returns 0 if successful, else an error is returned with the remaining time in
|
|
|
|
* the timeout parameter.
|
|
|
|
* -ETIME: object is still busy after timeout
|
|
|
|
* -ERESTARTSYS: signal interrupted the wait
|
|
|
|
* -ENONENT: object doesn't exist
|
|
|
|
* Also possible, but rare:
|
|
|
|
* -EAGAIN: GPU wedged
|
|
|
|
* -ENOMEM: damn
|
|
|
|
* -ENODEV: Internal IRQ fail
|
|
|
|
* -E?: The add request failed
|
|
|
|
*
|
|
|
|
* The wait ioctl with a timeout of 0 reimplements the busy ioctl. With any
|
|
|
|
* non-zero timeout parameter the wait ioctl will wait for the given number of
|
|
|
|
* nanoseconds on an object becoming unbusy. Since the wait itself does so
|
|
|
|
* without holding struct_mutex the object may become re-busied before this
|
|
|
|
* function completes. A similar but shorter * race condition exists in the busy
|
|
|
|
* ioctl
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
i915_gem_wait_ioctl(struct drm_device *dev, void *data, struct drm_file *file)
|
|
|
|
{
|
drm/i915: create a race-free reset detection
With the previous patch the state transition handling of the reset
code itself is now (hopefully) race free and solid. But that still
leaves out everyone else - with the various lock-free wait paths
we have there's the possibility that the reset happens between the
point where we read the seqno we should wait on and the actual wait.
And if __wait_seqno then never sees the RESET_IN_PROGRESS state, we'll
happily wait for a seqno which will in all likelyhood never signal.
In practice this is not a big problem since the X server gets
constantly interrupted, and can then submit more work (hopefully) to
unblock everyone else: As soon as a new seqno write lands, all waiters
will unblock. But running the i-g-t reset testcase ZZ_hangman can
expose this race, especially on slower hw with fewer cpu cores.
Now looking forward to ARB_robustness and friends that's not the best
possible behaviour, hence this patch adds a reset_counter to be able
to detect any reset, even if a given thread never observed the
in-progress state.
The important part is to correctly order things:
- The write side needs to increment the counter after any seqno gets
reset. Hence we need to do that at the end of the reset work, and
again wake everyone up. We also need to place a barrier in between
any possible seqno changes and the counter increment, since any
unlock operations only guarantee that nothing leaks out, but not
that at later load operation gets moved ahead.
- On the read side we need to ensure that no reset can sneak in and
invalidate the seqno. In all cases we can use the one-sided barrier
that unlock operations guarantee (of the lock protecting the
respective seqno/ring pair) to ensure correct ordering. Hence it is
sufficient to place the atomic read before the mutex/spin_unlock and
no additional barriers are required.
The end-result of all this is that we need to wake up everyone twice
in a reset operation:
- First, before the reset starts, to get any lockholders of the locks,
so that the reset can proceed.
- Second, after the reset is completed, to allow waiters to properly
and reliably detect the reset condition and bail out.
I admit that this entire reset_counter thing smells a bit like
overkill, but I think it's justified since it makes it really explicit
what the bail-out condition is. And we need a reset counter anyway to
implement ARB_robustness, and imo with finer-grained locking on the
horizont this is the most resilient scheme I could think of.
v2: Drop spurious change in the wait_for_error EXIT_COND - we only
need to wait until we leave the reset-in-progress wedged state.
v3: Don't play tricks with barriers in the throttle ioctl, the
spin_unlock is barrier enough.
I've also considered using a little helper to grab the current
reset_counter, but then decided that hiding the atomic_read isn't a
great idea, since having it explicitly show up in the code is a nice
remainder to reviews to check the memory barriers.
v4: Add a comment to explain why we need to fall through in
__wait_seqno in the end variable assignments.
v5: Review from Damien:
- s/smb/smp/ in a comment
- don't increment the reset counter after we've set it to WEDGED. Now
we (again) properly wedge the gpu when the reset fails.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-06 15:01:42 +07:00
|
|
|
drm_i915_private_t *dev_priv = dev->dev_private;
|
2012-05-25 05:03:10 +07:00
|
|
|
struct drm_i915_gem_wait *args = data;
|
|
|
|
struct drm_i915_gem_object *obj;
|
|
|
|
struct intel_ring_buffer *ring = NULL;
|
2012-06-06 05:24:24 +07:00
|
|
|
struct timespec timeout_stack, *timeout = NULL;
|
drm/i915: create a race-free reset detection
With the previous patch the state transition handling of the reset
code itself is now (hopefully) race free and solid. But that still
leaves out everyone else - with the various lock-free wait paths
we have there's the possibility that the reset happens between the
point where we read the seqno we should wait on and the actual wait.
And if __wait_seqno then never sees the RESET_IN_PROGRESS state, we'll
happily wait for a seqno which will in all likelyhood never signal.
In practice this is not a big problem since the X server gets
constantly interrupted, and can then submit more work (hopefully) to
unblock everyone else: As soon as a new seqno write lands, all waiters
will unblock. But running the i-g-t reset testcase ZZ_hangman can
expose this race, especially on slower hw with fewer cpu cores.
Now looking forward to ARB_robustness and friends that's not the best
possible behaviour, hence this patch adds a reset_counter to be able
to detect any reset, even if a given thread never observed the
in-progress state.
The important part is to correctly order things:
- The write side needs to increment the counter after any seqno gets
reset. Hence we need to do that at the end of the reset work, and
again wake everyone up. We also need to place a barrier in between
any possible seqno changes and the counter increment, since any
unlock operations only guarantee that nothing leaks out, but not
that at later load operation gets moved ahead.
- On the read side we need to ensure that no reset can sneak in and
invalidate the seqno. In all cases we can use the one-sided barrier
that unlock operations guarantee (of the lock protecting the
respective seqno/ring pair) to ensure correct ordering. Hence it is
sufficient to place the atomic read before the mutex/spin_unlock and
no additional barriers are required.
The end-result of all this is that we need to wake up everyone twice
in a reset operation:
- First, before the reset starts, to get any lockholders of the locks,
so that the reset can proceed.
- Second, after the reset is completed, to allow waiters to properly
and reliably detect the reset condition and bail out.
I admit that this entire reset_counter thing smells a bit like
overkill, but I think it's justified since it makes it really explicit
what the bail-out condition is. And we need a reset counter anyway to
implement ARB_robustness, and imo with finer-grained locking on the
horizont this is the most resilient scheme I could think of.
v2: Drop spurious change in the wait_for_error EXIT_COND - we only
need to wait until we leave the reset-in-progress wedged state.
v3: Don't play tricks with barriers in the throttle ioctl, the
spin_unlock is barrier enough.
I've also considered using a little helper to grab the current
reset_counter, but then decided that hiding the atomic_read isn't a
great idea, since having it explicitly show up in the code is a nice
remainder to reviews to check the memory barriers.
v4: Add a comment to explain why we need to fall through in
__wait_seqno in the end variable assignments.
v5: Review from Damien:
- s/smb/smp/ in a comment
- don't increment the reset counter after we've set it to WEDGED. Now
we (again) properly wedge the gpu when the reset fails.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-06 15:01:42 +07:00
|
|
|
unsigned reset_counter;
|
2012-05-25 05:03:10 +07:00
|
|
|
u32 seqno = 0;
|
|
|
|
int ret = 0;
|
|
|
|
|
2012-06-06 05:24:24 +07:00
|
|
|
if (args->timeout_ns >= 0) {
|
|
|
|
timeout_stack = ns_to_timespec(args->timeout_ns);
|
|
|
|
timeout = &timeout_stack;
|
|
|
|
}
|
2012-05-25 05:03:10 +07:00
|
|
|
|
|
|
|
ret = i915_mutex_lock_interruptible(dev);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
obj = to_intel_bo(drm_gem_object_lookup(dev, file, args->bo_handle));
|
|
|
|
if (&obj->base == NULL) {
|
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
return -ENOENT;
|
|
|
|
}
|
|
|
|
|
2012-06-01 20:21:23 +07:00
|
|
|
/* Need to make sure the object gets inactive eventually. */
|
|
|
|
ret = i915_gem_object_flush_active(obj);
|
2012-05-25 05:03:10 +07:00
|
|
|
if (ret)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
if (obj->active) {
|
2012-07-20 18:41:01 +07:00
|
|
|
seqno = obj->last_read_seqno;
|
2012-05-25 05:03:10 +07:00
|
|
|
ring = obj->ring;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (seqno == 0)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
/* Do this after OLR check to make sure we make forward progress polling
|
|
|
|
* on this IOCTL with a 0 timeout (like busy ioctl)
|
|
|
|
*/
|
|
|
|
if (!args->timeout_ns) {
|
|
|
|
ret = -ETIME;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
drm_gem_object_unreference(&obj->base);
|
drm/i915: create a race-free reset detection
With the previous patch the state transition handling of the reset
code itself is now (hopefully) race free and solid. But that still
leaves out everyone else - with the various lock-free wait paths
we have there's the possibility that the reset happens between the
point where we read the seqno we should wait on and the actual wait.
And if __wait_seqno then never sees the RESET_IN_PROGRESS state, we'll
happily wait for a seqno which will in all likelyhood never signal.
In practice this is not a big problem since the X server gets
constantly interrupted, and can then submit more work (hopefully) to
unblock everyone else: As soon as a new seqno write lands, all waiters
will unblock. But running the i-g-t reset testcase ZZ_hangman can
expose this race, especially on slower hw with fewer cpu cores.
Now looking forward to ARB_robustness and friends that's not the best
possible behaviour, hence this patch adds a reset_counter to be able
to detect any reset, even if a given thread never observed the
in-progress state.
The important part is to correctly order things:
- The write side needs to increment the counter after any seqno gets
reset. Hence we need to do that at the end of the reset work, and
again wake everyone up. We also need to place a barrier in between
any possible seqno changes and the counter increment, since any
unlock operations only guarantee that nothing leaks out, but not
that at later load operation gets moved ahead.
- On the read side we need to ensure that no reset can sneak in and
invalidate the seqno. In all cases we can use the one-sided barrier
that unlock operations guarantee (of the lock protecting the
respective seqno/ring pair) to ensure correct ordering. Hence it is
sufficient to place the atomic read before the mutex/spin_unlock and
no additional barriers are required.
The end-result of all this is that we need to wake up everyone twice
in a reset operation:
- First, before the reset starts, to get any lockholders of the locks,
so that the reset can proceed.
- Second, after the reset is completed, to allow waiters to properly
and reliably detect the reset condition and bail out.
I admit that this entire reset_counter thing smells a bit like
overkill, but I think it's justified since it makes it really explicit
what the bail-out condition is. And we need a reset counter anyway to
implement ARB_robustness, and imo with finer-grained locking on the
horizont this is the most resilient scheme I could think of.
v2: Drop spurious change in the wait_for_error EXIT_COND - we only
need to wait until we leave the reset-in-progress wedged state.
v3: Don't play tricks with barriers in the throttle ioctl, the
spin_unlock is barrier enough.
I've also considered using a little helper to grab the current
reset_counter, but then decided that hiding the atomic_read isn't a
great idea, since having it explicitly show up in the code is a nice
remainder to reviews to check the memory barriers.
v4: Add a comment to explain why we need to fall through in
__wait_seqno in the end variable assignments.
v5: Review from Damien:
- s/smb/smp/ in a comment
- don't increment the reset counter after we've set it to WEDGED. Now
we (again) properly wedge the gpu when the reset fails.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-06 15:01:42 +07:00
|
|
|
reset_counter = atomic_read(&dev_priv->gpu_error.reset_counter);
|
2012-05-25 05:03:10 +07:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
|
drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-25 23:34:56 +07:00
|
|
|
ret = __wait_seqno(ring, seqno, reset_counter, true, timeout, file->driver_priv);
|
2013-04-26 20:22:46 +07:00
|
|
|
if (timeout)
|
2012-06-06 05:24:24 +07:00
|
|
|
args->timeout_ns = timespec_to_ns(timeout);
|
2012-05-25 05:03:10 +07:00
|
|
|
return ret;
|
|
|
|
|
|
|
|
out:
|
|
|
|
drm_gem_object_unreference(&obj->base);
|
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-04-12 01:18:19 +07:00
|
|
|
/**
|
|
|
|
* i915_gem_object_sync - sync an object to a ring.
|
|
|
|
*
|
|
|
|
* @obj: object which may be in use on another ring.
|
|
|
|
* @to: ring we wish to use the object on. May be NULL.
|
|
|
|
*
|
|
|
|
* This code is meant to abstract object synchronization with the GPU.
|
|
|
|
* Calling with NULL implies synchronizing the object with the CPU
|
|
|
|
* rather than a particular GPU ring.
|
|
|
|
*
|
|
|
|
* Returns 0 if successful, else propagates up the lower layer error.
|
|
|
|
*/
|
2012-04-06 04:47:36 +07:00
|
|
|
int
|
|
|
|
i915_gem_object_sync(struct drm_i915_gem_object *obj,
|
|
|
|
struct intel_ring_buffer *to)
|
|
|
|
{
|
|
|
|
struct intel_ring_buffer *from = obj->ring;
|
|
|
|
u32 seqno;
|
|
|
|
int ret, idx;
|
|
|
|
|
|
|
|
if (from == NULL || to == from)
|
|
|
|
return 0;
|
|
|
|
|
2012-04-12 01:18:19 +07:00
|
|
|
if (to == NULL || !i915_semaphore_is_enabled(obj->base.dev))
|
2012-07-20 18:41:01 +07:00
|
|
|
return i915_gem_object_wait_rendering(obj, false);
|
2012-04-06 04:47:36 +07:00
|
|
|
|
|
|
|
idx = intel_ring_sync_index(from, to);
|
|
|
|
|
2012-07-20 18:41:01 +07:00
|
|
|
seqno = obj->last_read_seqno;
|
2012-04-06 04:47:36 +07:00
|
|
|
if (seqno <= from->sync_seqno[idx])
|
|
|
|
return 0;
|
|
|
|
|
2012-04-26 10:50:12 +07:00
|
|
|
ret = i915_gem_check_olr(obj->ring, seqno);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2012-04-06 04:47:36 +07:00
|
|
|
|
2013-09-25 17:43:28 +07:00
|
|
|
trace_i915_gem_ring_sync_to(from, to, seqno);
|
2012-04-12 01:18:21 +07:00
|
|
|
ret = to->sync_to(to, from, seqno);
|
2012-04-12 01:18:20 +07:00
|
|
|
if (!ret)
|
2012-11-28 22:18:45 +07:00
|
|
|
/* We use last_read_seqno because sync_to()
|
|
|
|
* might have just caused seqno wrap under
|
|
|
|
* the radar.
|
|
|
|
*/
|
|
|
|
from->sync_seqno[idx] = obj->last_read_seqno;
|
2012-04-06 04:47:36 +07:00
|
|
|
|
2012-04-12 01:18:20 +07:00
|
|
|
return ret;
|
2012-04-06 04:47:36 +07:00
|
|
|
}
|
|
|
|
|
2011-04-14 04:06:03 +07:00
|
|
|
static void i915_gem_object_finish_gtt(struct drm_i915_gem_object *obj)
|
|
|
|
{
|
|
|
|
u32 old_write_domain, old_read_domains;
|
|
|
|
|
|
|
|
/* Force a pagefault for domain tracking on next user access */
|
|
|
|
i915_gem_release_mmap(obj);
|
|
|
|
|
2011-06-25 11:02:59 +07:00
|
|
|
if ((obj->base.read_domains & I915_GEM_DOMAIN_GTT) == 0)
|
|
|
|
return;
|
|
|
|
|
2012-10-10 01:24:38 +07:00
|
|
|
/* Wait for any direct GTT access to complete */
|
|
|
|
mb();
|
|
|
|
|
2011-04-14 04:06:03 +07:00
|
|
|
old_read_domains = obj->base.read_domains;
|
|
|
|
old_write_domain = obj->base.write_domain;
|
|
|
|
|
|
|
|
obj->base.read_domains &= ~I915_GEM_DOMAIN_GTT;
|
|
|
|
obj->base.write_domain &= ~I915_GEM_DOMAIN_GTT;
|
|
|
|
|
|
|
|
trace_i915_gem_object_change_domain(obj,
|
|
|
|
old_read_domains,
|
|
|
|
old_write_domain);
|
|
|
|
}
|
|
|
|
|
drm/i915: plumb VM into bind/unbind code
As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).
This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.
> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-01 07:00:10 +07:00
|
|
|
int i915_vma_unbind(struct i915_vma *vma)
|
2008-07-31 02:06:12 +07:00
|
|
|
{
|
drm/i915: plumb VM into bind/unbind code
As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).
This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.
> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-01 07:00:10 +07:00
|
|
|
struct drm_i915_gem_object *obj = vma->obj;
|
2012-02-09 23:15:47 +07:00
|
|
|
drm_i915_private_t *dev_priv = obj->base.dev->dev_private;
|
2013-01-08 17:53:09 +07:00
|
|
|
int ret;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2013-08-26 16:23:47 +07:00
|
|
|
/* For now we only ever use 1 vma per object */
|
|
|
|
WARN_ON(!list_is_singular(&obj->vma_list));
|
|
|
|
|
drm/i915: plumb VM into bind/unbind code
As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).
This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.
> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-01 07:00:10 +07:00
|
|
|
if (list_empty(&vma->vma_link))
|
2008-07-31 02:06:12 +07:00
|
|
|
return 0;
|
|
|
|
|
2013-08-30 00:50:31 +07:00
|
|
|
if (!drm_mm_node_allocated(&vma->node)) {
|
|
|
|
i915_gem_vma_destroy(vma);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2013-08-14 08:09:06 +07:00
|
|
|
|
2012-05-25 01:11:20 +07:00
|
|
|
if (obj->pin_count)
|
|
|
|
return -EBUSY;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2012-08-20 16:23:27 +07:00
|
|
|
BUG_ON(obj->pages == NULL);
|
|
|
|
|
2011-04-14 04:04:09 +07:00
|
|
|
ret = i915_gem_object_finish_gpu(obj);
|
2012-04-24 21:47:31 +07:00
|
|
|
if (ret)
|
2011-04-14 04:04:09 +07:00
|
|
|
return ret;
|
|
|
|
/* Continue on if we fail due to EIO, the GPU is hung so we
|
|
|
|
* should be safe and we need to cleanup or else we might
|
|
|
|
* cause memory corruption through use-after-free.
|
|
|
|
*/
|
|
|
|
|
2011-04-14 04:06:03 +07:00
|
|
|
i915_gem_object_finish_gtt(obj);
|
2009-09-10 01:50:45 +07:00
|
|
|
|
2009-12-15 23:50:00 +07:00
|
|
|
/* release the fence reg _after_ flushing */
|
2010-11-10 23:40:20 +07:00
|
|
|
ret = i915_gem_object_put_fence(obj);
|
2012-04-24 21:47:31 +07:00
|
|
|
if (ret)
|
2010-11-10 23:40:20 +07:00
|
|
|
return ret;
|
2009-12-15 23:50:00 +07:00
|
|
|
|
drm/i915: plumb VM into bind/unbind code
As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).
This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.
> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-01 07:00:10 +07:00
|
|
|
trace_i915_vma_unbind(vma);
|
2011-02-03 18:57:46 +07:00
|
|
|
|
2012-02-16 05:50:22 +07:00
|
|
|
if (obj->has_global_gtt_mapping)
|
|
|
|
i915_gem_gtt_unbind_object(obj);
|
2012-02-09 23:15:47 +07:00
|
|
|
if (obj->has_aliasing_ppgtt_mapping) {
|
|
|
|
i915_ppgtt_unbind_object(dev_priv->mm.aliasing_ppgtt, obj);
|
|
|
|
obj->has_aliasing_ppgtt_mapping = 0;
|
|
|
|
}
|
2012-02-16 05:50:21 +07:00
|
|
|
i915_gem_gtt_finish_object(obj);
|
2012-02-09 23:15:47 +07:00
|
|
|
|
2013-08-01 07:00:14 +07:00
|
|
|
list_del(&vma->mm_list);
|
2010-11-04 23:11:09 +07:00
|
|
|
/* Avoid an unnecessary call to unbind on rebind. */
|
2013-08-01 07:00:13 +07:00
|
|
|
if (i915_is_ggtt(vma->vm))
|
|
|
|
obj->map_and_fenceable = true;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2013-07-18 02:19:03 +07:00
|
|
|
drm_mm_remove_node(&vma->node);
|
|
|
|
i915_gem_vma_destroy(vma);
|
|
|
|
|
|
|
|
/* Since the unbound list is global, only move to that list if
|
2013-08-26 16:23:47 +07:00
|
|
|
* no more VMAs exist. */
|
2013-07-18 02:19:03 +07:00
|
|
|
if (list_empty(&obj->vma_list))
|
|
|
|
list_move_tail(&obj->global_list, &dev_priv->mm.unbound_list);
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2013-12-04 16:59:09 +07:00
|
|
|
/* And finally now the object is completely decoupled from this vma,
|
|
|
|
* we can drop its hold on the backing storage and allow it to be
|
|
|
|
* reaped by the shrinker.
|
|
|
|
*/
|
|
|
|
i915_gem_object_unpin_pages(obj);
|
|
|
|
|
2011-01-08 00:09:48 +07:00
|
|
|
return 0;
|
2010-11-26 01:00:26 +07:00
|
|
|
}
|
|
|
|
|
drm/i915: plumb VM into bind/unbind code
As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).
This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.
> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-01 07:00:10 +07:00
|
|
|
/**
|
|
|
|
* Unbinds an object from the global GTT aperture.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
i915_gem_object_ggtt_unbind(struct drm_i915_gem_object *obj)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
|
|
|
|
struct i915_address_space *ggtt = &dev_priv->gtt.base;
|
|
|
|
|
2013-08-09 16:44:11 +07:00
|
|
|
if (!i915_gem_obj_ggtt_bound(obj))
|
drm/i915: plumb VM into bind/unbind code
As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).
This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.
> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-01 07:00:10 +07:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (obj->pin_count)
|
|
|
|
return -EBUSY;
|
|
|
|
|
|
|
|
BUG_ON(obj->pages == NULL);
|
|
|
|
|
|
|
|
return i915_vma_unbind(i915_gem_obj_to_vma(obj, ggtt));
|
|
|
|
}
|
|
|
|
|
2012-04-27 06:02:58 +07:00
|
|
|
int i915_gpu_idle(struct drm_device *dev)
|
2010-02-19 17:52:00 +07:00
|
|
|
{
|
|
|
|
drm_i915_private_t *dev_priv = dev->dev_private;
|
2012-05-11 20:29:30 +07:00
|
|
|
struct intel_ring_buffer *ring;
|
2010-12-04 18:30:53 +07:00
|
|
|
int ret, i;
|
2010-02-19 17:52:00 +07:00
|
|
|
|
|
|
|
/* Flush everything onto the inactive list. */
|
2012-05-11 20:29:30 +07:00
|
|
|
for_each_ring(ring, dev_priv, i) {
|
2012-08-15 04:35:14 +07:00
|
|
|
ret = i915_switch_context(ring, NULL, DEFAULT_CONTEXT_ID);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2012-11-27 23:22:54 +07:00
|
|
|
ret = intel_ring_idle(ring);
|
2010-12-04 18:30:53 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
2010-02-19 17:52:00 +07:00
|
|
|
|
2010-02-12 04:29:04 +07:00
|
|
|
return 0;
|
2010-02-19 17:52:00 +07:00
|
|
|
}
|
|
|
|
|
2012-04-17 21:31:30 +07:00
|
|
|
static void i965_write_fence_reg(struct drm_device *dev, int reg,
|
|
|
|
struct drm_i915_gem_object *obj)
|
2008-11-13 01:03:55 +07:00
|
|
|
{
|
|
|
|
drm_i915_private_t *dev_priv = dev->dev_private;
|
2013-01-08 02:47:34 +07:00
|
|
|
int fence_reg;
|
|
|
|
int fence_pitch_shift;
|
2008-11-13 01:03:55 +07:00
|
|
|
|
2013-01-08 02:47:34 +07:00
|
|
|
if (INTEL_INFO(dev)->gen >= 6) {
|
|
|
|
fence_reg = FENCE_REG_SANDYBRIDGE_0;
|
|
|
|
fence_pitch_shift = SANDYBRIDGE_FENCE_PITCH_SHIFT;
|
|
|
|
} else {
|
|
|
|
fence_reg = FENCE_REG_965_0;
|
|
|
|
fence_pitch_shift = I965_FENCE_PITCH_SHIFT;
|
|
|
|
}
|
|
|
|
|
drm/i915: Fix incoherence with fence updates on Sandybridge+
This hopefully fixes the root cause behind the workaround added in
commit 25ff1195f8a0b3724541ae7bbe331b4296de9c06
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Apr 4 21:31:03 2013 +0100
drm/i915: Workaround incoherence between fences and LLC across multiple CPUs
Thanks to further investigation by Jon Bloomfield, he realised that
the 64-bit register might be broken up by the hardware into two 32-bit
writes (a problem we have encountered elsewhere). This non-atomicity
would then cause an issue where a second thread would see an
intermediate register state (new high dword, old low dword), and this
register would randomly be used in preference to its own thread register.
This would cause the second thread to read from and write into a fairly
random tiled location. Breaking the operation into 3 explicit 32-bit
updates (first disable the fence, poke the upper bits, then poke the lower
bits and enable) ensures that, given proper serialisation between the
32-bit register write and the memory transfer, that the fence value is
always consistent.
Armed with this knowledge, we can explain how the previous workaround
work. The key to the corruption is that a second thread sees an
erroneous fence register that conflicts and overrides its own. By
serialising the fence update across all CPUs, we have a small window
where no GTT access is occurring and so hide the potential corruption.
This also leads to the conclusion that the earlier workaround was
incomplete.
v2: Be overly paranoid about the order in which fence updates become
visible to the GPU to make really sure that we turn the fence off before
doing the update, and then only switch the fence on afterwards.
Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Carsten Emde <C.Emde@osadl.org>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-10 19:36:23 +07:00
|
|
|
fence_reg += reg * 8;
|
|
|
|
|
|
|
|
/* To w/a incoherency with non-atomic 64-bit register updates,
|
|
|
|
* we split the 64-bit update into two 32-bit writes. In order
|
|
|
|
* for a partial fence not to be evaluated between writes, we
|
|
|
|
* precede the update with write to turn off the fence register,
|
|
|
|
* and only enable the fence as the last step.
|
|
|
|
*
|
|
|
|
* For extra levels of paranoia, we make sure each step lands
|
|
|
|
* before applying the next step.
|
|
|
|
*/
|
|
|
|
I915_WRITE(fence_reg, 0);
|
|
|
|
POSTING_READ(fence_reg);
|
|
|
|
|
2012-04-17 21:31:30 +07:00
|
|
|
if (obj) {
|
2013-07-06 04:41:04 +07:00
|
|
|
u32 size = i915_gem_obj_ggtt_size(obj);
|
drm/i915: Fix incoherence with fence updates on Sandybridge+
This hopefully fixes the root cause behind the workaround added in
commit 25ff1195f8a0b3724541ae7bbe331b4296de9c06
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Apr 4 21:31:03 2013 +0100
drm/i915: Workaround incoherence between fences and LLC across multiple CPUs
Thanks to further investigation by Jon Bloomfield, he realised that
the 64-bit register might be broken up by the hardware into two 32-bit
writes (a problem we have encountered elsewhere). This non-atomicity
would then cause an issue where a second thread would see an
intermediate register state (new high dword, old low dword), and this
register would randomly be used in preference to its own thread register.
This would cause the second thread to read from and write into a fairly
random tiled location. Breaking the operation into 3 explicit 32-bit
updates (first disable the fence, poke the upper bits, then poke the lower
bits and enable) ensures that, given proper serialisation between the
32-bit register write and the memory transfer, that the fence value is
always consistent.
Armed with this knowledge, we can explain how the previous workaround
work. The key to the corruption is that a second thread sees an
erroneous fence register that conflicts and overrides its own. By
serialising the fence update across all CPUs, we have a small window
where no GTT access is occurring and so hide the potential corruption.
This also leads to the conclusion that the earlier workaround was
incomplete.
v2: Be overly paranoid about the order in which fence updates become
visible to the GPU to make really sure that we turn the fence off before
doing the update, and then only switch the fence on afterwards.
Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Carsten Emde <C.Emde@osadl.org>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-10 19:36:23 +07:00
|
|
|
uint64_t val;
|
2008-11-13 01:03:55 +07:00
|
|
|
|
2013-07-06 04:41:04 +07:00
|
|
|
val = (uint64_t)((i915_gem_obj_ggtt_offset(obj) + size - 4096) &
|
2012-04-17 21:31:30 +07:00
|
|
|
0xfffff000) << 32;
|
2013-07-06 04:41:04 +07:00
|
|
|
val |= i915_gem_obj_ggtt_offset(obj) & 0xfffff000;
|
2013-01-08 02:47:34 +07:00
|
|
|
val |= (uint64_t)((obj->stride / 128) - 1) << fence_pitch_shift;
|
2012-04-17 21:31:30 +07:00
|
|
|
if (obj->tiling_mode == I915_TILING_Y)
|
|
|
|
val |= 1 << I965_FENCE_TILING_Y_SHIFT;
|
|
|
|
val |= I965_FENCE_REG_VALID;
|
2010-11-12 20:46:18 +07:00
|
|
|
|
drm/i915: Fix incoherence with fence updates on Sandybridge+
This hopefully fixes the root cause behind the workaround added in
commit 25ff1195f8a0b3724541ae7bbe331b4296de9c06
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Apr 4 21:31:03 2013 +0100
drm/i915: Workaround incoherence between fences and LLC across multiple CPUs
Thanks to further investigation by Jon Bloomfield, he realised that
the 64-bit register might be broken up by the hardware into two 32-bit
writes (a problem we have encountered elsewhere). This non-atomicity
would then cause an issue where a second thread would see an
intermediate register state (new high dword, old low dword), and this
register would randomly be used in preference to its own thread register.
This would cause the second thread to read from and write into a fairly
random tiled location. Breaking the operation into 3 explicit 32-bit
updates (first disable the fence, poke the upper bits, then poke the lower
bits and enable) ensures that, given proper serialisation between the
32-bit register write and the memory transfer, that the fence value is
always consistent.
Armed with this knowledge, we can explain how the previous workaround
work. The key to the corruption is that a second thread sees an
erroneous fence register that conflicts and overrides its own. By
serialising the fence update across all CPUs, we have a small window
where no GTT access is occurring and so hide the potential corruption.
This also leads to the conclusion that the earlier workaround was
incomplete.
v2: Be overly paranoid about the order in which fence updates become
visible to the GPU to make really sure that we turn the fence off before
doing the update, and then only switch the fence on afterwards.
Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Carsten Emde <C.Emde@osadl.org>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-10 19:36:23 +07:00
|
|
|
I915_WRITE(fence_reg + 4, val >> 32);
|
|
|
|
POSTING_READ(fence_reg + 4);
|
|
|
|
|
|
|
|
I915_WRITE(fence_reg + 0, val);
|
|
|
|
POSTING_READ(fence_reg);
|
|
|
|
} else {
|
|
|
|
I915_WRITE(fence_reg + 4, 0);
|
|
|
|
POSTING_READ(fence_reg + 4);
|
|
|
|
}
|
2008-11-13 01:03:55 +07:00
|
|
|
}
|
|
|
|
|
2012-04-17 21:31:30 +07:00
|
|
|
static void i915_write_fence_reg(struct drm_device *dev, int reg,
|
|
|
|
struct drm_i915_gem_object *obj)
|
2008-11-13 01:03:55 +07:00
|
|
|
{
|
|
|
|
drm_i915_private_t *dev_priv = dev->dev_private;
|
2012-04-17 21:31:30 +07:00
|
|
|
u32 val;
|
2008-11-13 01:03:55 +07:00
|
|
|
|
2012-04-17 21:31:30 +07:00
|
|
|
if (obj) {
|
2013-07-06 04:41:04 +07:00
|
|
|
u32 size = i915_gem_obj_ggtt_size(obj);
|
2012-04-17 21:31:30 +07:00
|
|
|
int pitch_val;
|
|
|
|
int tile_width;
|
2010-11-12 20:46:18 +07:00
|
|
|
|
2013-07-06 04:41:04 +07:00
|
|
|
WARN((i915_gem_obj_ggtt_offset(obj) & ~I915_FENCE_START_MASK) ||
|
2012-04-17 21:31:30 +07:00
|
|
|
(size & -size) != size ||
|
2013-07-06 04:41:04 +07:00
|
|
|
(i915_gem_obj_ggtt_offset(obj) & (size - 1)),
|
|
|
|
"object 0x%08lx [fenceable? %d] not 1M or pot-size (0x%08x) aligned\n",
|
|
|
|
i915_gem_obj_ggtt_offset(obj), obj->map_and_fenceable, size);
|
2010-11-12 20:46:18 +07:00
|
|
|
|
2012-04-17 21:31:30 +07:00
|
|
|
if (obj->tiling_mode == I915_TILING_Y && HAS_128_BYTE_Y_TILING(dev))
|
|
|
|
tile_width = 128;
|
|
|
|
else
|
|
|
|
tile_width = 512;
|
|
|
|
|
|
|
|
/* Note: pitch better be a power of two tile widths */
|
|
|
|
pitch_val = obj->stride / tile_width;
|
|
|
|
pitch_val = ffs(pitch_val) - 1;
|
|
|
|
|
2013-07-06 04:41:04 +07:00
|
|
|
val = i915_gem_obj_ggtt_offset(obj);
|
2012-04-17 21:31:30 +07:00
|
|
|
if (obj->tiling_mode == I915_TILING_Y)
|
|
|
|
val |= 1 << I830_FENCE_TILING_Y_SHIFT;
|
|
|
|
val |= I915_FENCE_SIZE_BITS(size);
|
|
|
|
val |= pitch_val << I830_FENCE_PITCH_SHIFT;
|
|
|
|
val |= I830_FENCE_REG_VALID;
|
|
|
|
} else
|
|
|
|
val = 0;
|
|
|
|
|
|
|
|
if (reg < 8)
|
|
|
|
reg = FENCE_REG_830_0 + reg * 4;
|
|
|
|
else
|
|
|
|
reg = FENCE_REG_945_8 + (reg - 8) * 4;
|
|
|
|
|
|
|
|
I915_WRITE(reg, val);
|
|
|
|
POSTING_READ(reg);
|
2008-11-13 01:03:55 +07:00
|
|
|
}
|
|
|
|
|
2012-04-17 21:31:30 +07:00
|
|
|
static void i830_write_fence_reg(struct drm_device *dev, int reg,
|
|
|
|
struct drm_i915_gem_object *obj)
|
2008-11-13 01:03:55 +07:00
|
|
|
{
|
|
|
|
drm_i915_private_t *dev_priv = dev->dev_private;
|
|
|
|
uint32_t val;
|
|
|
|
|
2012-04-17 21:31:30 +07:00
|
|
|
if (obj) {
|
2013-07-06 04:41:04 +07:00
|
|
|
u32 size = i915_gem_obj_ggtt_size(obj);
|
2012-04-17 21:31:30 +07:00
|
|
|
uint32_t pitch_val;
|
2008-11-13 01:03:55 +07:00
|
|
|
|
2013-07-06 04:41:04 +07:00
|
|
|
WARN((i915_gem_obj_ggtt_offset(obj) & ~I830_FENCE_START_MASK) ||
|
2012-04-17 21:31:30 +07:00
|
|
|
(size & -size) != size ||
|
2013-07-06 04:41:04 +07:00
|
|
|
(i915_gem_obj_ggtt_offset(obj) & (size - 1)),
|
|
|
|
"object 0x%08lx not 512K or pot-size 0x%08x aligned\n",
|
|
|
|
i915_gem_obj_ggtt_offset(obj), size);
|
2009-05-27 07:44:56 +07:00
|
|
|
|
2012-04-17 21:31:30 +07:00
|
|
|
pitch_val = obj->stride / 128;
|
|
|
|
pitch_val = ffs(pitch_val) - 1;
|
2008-11-13 01:03:55 +07:00
|
|
|
|
2013-07-06 04:41:04 +07:00
|
|
|
val = i915_gem_obj_ggtt_offset(obj);
|
2012-04-17 21:31:30 +07:00
|
|
|
if (obj->tiling_mode == I915_TILING_Y)
|
|
|
|
val |= 1 << I830_FENCE_TILING_Y_SHIFT;
|
|
|
|
val |= I830_FENCE_SIZE_BITS(size);
|
|
|
|
val |= pitch_val << I830_FENCE_PITCH_SHIFT;
|
|
|
|
val |= I830_FENCE_REG_VALID;
|
|
|
|
} else
|
|
|
|
val = 0;
|
2010-11-12 20:46:18 +07:00
|
|
|
|
2012-04-17 21:31:30 +07:00
|
|
|
I915_WRITE(FENCE_REG_830_0 + reg * 4, val);
|
|
|
|
POSTING_READ(FENCE_REG_830_0 + reg * 4);
|
|
|
|
}
|
|
|
|
|
2012-10-10 01:24:37 +07:00
|
|
|
inline static bool i915_gem_object_needs_mb(struct drm_i915_gem_object *obj)
|
|
|
|
{
|
|
|
|
return obj && obj->base.read_domains & I915_GEM_DOMAIN_GTT;
|
|
|
|
}
|
|
|
|
|
2012-04-17 21:31:30 +07:00
|
|
|
static void i915_gem_write_fence(struct drm_device *dev, int reg,
|
|
|
|
struct drm_i915_gem_object *obj)
|
|
|
|
{
|
2012-10-10 01:24:37 +07:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
|
|
|
|
|
|
|
/* Ensure that all CPU reads are completed before installing a fence
|
|
|
|
* and all writes before removing the fence.
|
|
|
|
*/
|
|
|
|
if (i915_gem_object_needs_mb(dev_priv->fence_regs[reg].obj))
|
|
|
|
mb();
|
|
|
|
|
2013-07-17 19:51:28 +07:00
|
|
|
WARN(obj && (!obj->stride || !obj->tiling_mode),
|
|
|
|
"bogus fence setup with stride: 0x%x, tiling mode: %i\n",
|
|
|
|
obj->stride, obj->tiling_mode);
|
|
|
|
|
2012-04-17 21:31:30 +07:00
|
|
|
switch (INTEL_INFO(dev)->gen) {
|
2013-11-03 11:07:03 +07:00
|
|
|
case 8:
|
2012-04-17 21:31:30 +07:00
|
|
|
case 7:
|
2013-01-08 02:47:34 +07:00
|
|
|
case 6:
|
2012-04-17 21:31:30 +07:00
|
|
|
case 5:
|
|
|
|
case 4: i965_write_fence_reg(dev, reg, obj); break;
|
|
|
|
case 3: i915_write_fence_reg(dev, reg, obj); break;
|
|
|
|
case 2: i830_write_fence_reg(dev, reg, obj); break;
|
2012-12-19 01:31:22 +07:00
|
|
|
default: BUG();
|
2012-04-17 21:31:30 +07:00
|
|
|
}
|
2012-10-10 01:24:37 +07:00
|
|
|
|
|
|
|
/* And similarly be paranoid that no direct access to this region
|
|
|
|
* is reordered to before the fence is installed.
|
|
|
|
*/
|
|
|
|
if (i915_gem_object_needs_mb(obj))
|
|
|
|
mb();
|
2008-11-13 01:03:55 +07:00
|
|
|
}
|
|
|
|
|
2012-04-17 21:31:31 +07:00
|
|
|
static inline int fence_number(struct drm_i915_private *dev_priv,
|
|
|
|
struct drm_i915_fence_reg *fence)
|
|
|
|
{
|
|
|
|
return fence - dev_priv->fence_regs;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void i915_gem_object_update_fence(struct drm_i915_gem_object *obj,
|
|
|
|
struct drm_i915_fence_reg *fence,
|
|
|
|
bool enable)
|
|
|
|
{
|
2013-05-22 23:08:06 +07:00
|
|
|
struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
|
2013-07-10 19:36:24 +07:00
|
|
|
int reg = fence_number(dev_priv, fence);
|
|
|
|
|
|
|
|
i915_gem_write_fence(obj->base.dev, reg, enable ? obj : NULL);
|
2012-04-17 21:31:31 +07:00
|
|
|
|
|
|
|
if (enable) {
|
2013-07-10 19:36:24 +07:00
|
|
|
obj->fence_reg = reg;
|
2012-04-17 21:31:31 +07:00
|
|
|
fence->obj = obj;
|
|
|
|
list_move_tail(&fence->lru_list, &dev_priv->mm.fence_list);
|
|
|
|
} else {
|
|
|
|
obj->fence_reg = I915_FENCE_REG_NONE;
|
|
|
|
fence->obj = NULL;
|
|
|
|
list_del_init(&fence->lru_list);
|
|
|
|
}
|
2013-07-17 19:51:28 +07:00
|
|
|
obj->fence_dirty = false;
|
2012-04-17 21:31:31 +07:00
|
|
|
}
|
|
|
|
|
2010-11-10 23:40:20 +07:00
|
|
|
static int
|
2012-10-10 01:24:37 +07:00
|
|
|
i915_gem_object_wait_fence(struct drm_i915_gem_object *obj)
|
2010-11-10 23:40:20 +07:00
|
|
|
{
|
2012-04-17 21:31:27 +07:00
|
|
|
if (obj->last_fenced_seqno) {
|
2012-07-20 18:41:04 +07:00
|
|
|
int ret = i915_wait_seqno(obj->ring, obj->last_fenced_seqno);
|
2012-04-17 21:31:29 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
2010-11-10 23:40:20 +07:00
|
|
|
|
|
|
|
obj->last_fenced_seqno = 0;
|
|
|
|
}
|
|
|
|
|
2012-07-20 18:41:04 +07:00
|
|
|
obj->fenced_gpu_access = false;
|
2010-11-10 23:40:20 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
i915_gem_object_put_fence(struct drm_i915_gem_object *obj)
|
|
|
|
{
|
2012-04-17 21:31:31 +07:00
|
|
|
struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
|
2013-03-26 18:29:27 +07:00
|
|
|
struct drm_i915_fence_reg *fence;
|
2010-11-10 23:40:20 +07:00
|
|
|
int ret;
|
|
|
|
|
2012-10-10 01:24:37 +07:00
|
|
|
ret = i915_gem_object_wait_fence(obj);
|
2010-11-10 23:40:20 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2012-04-17 21:31:31 +07:00
|
|
|
if (obj->fence_reg == I915_FENCE_REG_NONE)
|
|
|
|
return 0;
|
2010-11-10 23:40:20 +07:00
|
|
|
|
2013-03-26 18:29:27 +07:00
|
|
|
fence = &dev_priv->fence_regs[obj->fence_reg];
|
|
|
|
|
2012-04-17 21:31:31 +07:00
|
|
|
i915_gem_object_fence_lost(obj);
|
2013-03-26 18:29:27 +07:00
|
|
|
i915_gem_object_update_fence(obj, fence, false);
|
2010-11-10 23:40:20 +07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct drm_i915_fence_reg *
|
2012-04-17 21:31:25 +07:00
|
|
|
i915_find_fence_reg(struct drm_device *dev)
|
2010-02-19 17:51:58 +07:00
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2012-04-17 21:31:28 +07:00
|
|
|
struct drm_i915_fence_reg *reg, *avail;
|
2010-11-10 23:40:20 +07:00
|
|
|
int i;
|
2010-02-19 17:51:58 +07:00
|
|
|
|
|
|
|
/* First try to find a free reg */
|
2010-11-10 23:40:20 +07:00
|
|
|
avail = NULL;
|
2010-02-19 17:51:58 +07:00
|
|
|
for (i = dev_priv->fence_reg_start; i < dev_priv->num_fence_regs; i++) {
|
|
|
|
reg = &dev_priv->fence_regs[i];
|
|
|
|
if (!reg->obj)
|
2010-11-10 23:40:20 +07:00
|
|
|
return reg;
|
2010-02-19 17:51:58 +07:00
|
|
|
|
2011-12-14 19:57:08 +07:00
|
|
|
if (!reg->pin_count)
|
2010-11-10 23:40:20 +07:00
|
|
|
avail = reg;
|
2010-02-19 17:51:58 +07:00
|
|
|
}
|
|
|
|
|
2010-11-10 23:40:20 +07:00
|
|
|
if (avail == NULL)
|
|
|
|
return NULL;
|
2010-02-19 17:51:58 +07:00
|
|
|
|
|
|
|
/* None available, try to steal one or wait for a user to finish */
|
2010-11-10 23:40:20 +07:00
|
|
|
list_for_each_entry(reg, &dev_priv->mm.fence_list, lru_list) {
|
2011-12-14 19:57:08 +07:00
|
|
|
if (reg->pin_count)
|
2010-02-19 17:51:58 +07:00
|
|
|
continue;
|
|
|
|
|
2012-04-17 21:31:28 +07:00
|
|
|
return reg;
|
2010-02-19 17:51:58 +07:00
|
|
|
}
|
|
|
|
|
2012-04-17 21:31:28 +07:00
|
|
|
return NULL;
|
2010-02-19 17:51:58 +07:00
|
|
|
}
|
|
|
|
|
2008-11-13 01:03:55 +07:00
|
|
|
/**
|
2012-03-22 22:10:00 +07:00
|
|
|
* i915_gem_object_get_fence - set up fencing for an object
|
2008-11-13 01:03:55 +07:00
|
|
|
* @obj: object to map through a fence reg
|
|
|
|
*
|
|
|
|
* When mapping objects through the GTT, userspace wants to be able to write
|
|
|
|
* to them without having to worry about swizzling if the object is tiled.
|
|
|
|
* This function walks the fence regs looking for a free one for @obj,
|
|
|
|
* stealing one if it can't find any.
|
|
|
|
*
|
|
|
|
* It then sets up the reg based on the object's properties: address, pitch
|
|
|
|
* and tiling format.
|
2012-03-22 22:10:00 +07:00
|
|
|
*
|
|
|
|
* For an untiled surface, this removes any existing fence.
|
2008-11-13 01:03:55 +07:00
|
|
|
*/
|
2009-06-18 04:08:52 +07:00
|
|
|
int
|
2012-04-17 21:31:24 +07:00
|
|
|
i915_gem_object_get_fence(struct drm_i915_gem_object *obj)
|
2008-11-13 01:03:55 +07:00
|
|
|
{
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_device *dev = obj->base.dev;
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2012-04-17 21:31:33 +07:00
|
|
|
bool enable = obj->tiling_mode != I915_TILING_NONE;
|
2010-11-10 23:40:20 +07:00
|
|
|
struct drm_i915_fence_reg *reg;
|
2010-02-19 17:51:58 +07:00
|
|
|
int ret;
|
2008-11-13 01:03:55 +07:00
|
|
|
|
2012-04-17 21:31:33 +07:00
|
|
|
/* Have we updated the tiling parameters upon the object and so
|
|
|
|
* will need to serialise the write to the associated fence register?
|
|
|
|
*/
|
2012-04-21 22:23:23 +07:00
|
|
|
if (obj->fence_dirty) {
|
2012-10-10 01:24:37 +07:00
|
|
|
ret = i915_gem_object_wait_fence(obj);
|
2012-04-17 21:31:33 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
2012-03-22 22:10:00 +07:00
|
|
|
|
2010-11-10 23:40:20 +07:00
|
|
|
/* Just update our place in the LRU if our fence is getting reused. */
|
2010-11-09 02:18:58 +07:00
|
|
|
if (obj->fence_reg != I915_FENCE_REG_NONE) {
|
|
|
|
reg = &dev_priv->fence_regs[obj->fence_reg];
|
2012-04-21 22:23:23 +07:00
|
|
|
if (!obj->fence_dirty) {
|
2012-04-17 21:31:33 +07:00
|
|
|
list_move_tail(®->lru_list,
|
|
|
|
&dev_priv->mm.fence_list);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
} else if (enable) {
|
|
|
|
reg = i915_find_fence_reg(dev);
|
|
|
|
if (reg == NULL)
|
|
|
|
return -EDEADLK;
|
2010-11-10 23:40:20 +07:00
|
|
|
|
2012-04-17 21:31:33 +07:00
|
|
|
if (reg->obj) {
|
|
|
|
struct drm_i915_gem_object *old = reg->obj;
|
|
|
|
|
2012-10-10 01:24:37 +07:00
|
|
|
ret = i915_gem_object_wait_fence(old);
|
2011-03-17 22:23:22 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2012-04-17 21:31:33 +07:00
|
|
|
i915_gem_object_fence_lost(old);
|
2011-03-17 22:23:22 +07:00
|
|
|
}
|
2012-04-17 21:31:33 +07:00
|
|
|
} else
|
2009-08-30 02:49:51 +07:00
|
|
|
return 0;
|
|
|
|
|
2012-04-17 21:31:33 +07:00
|
|
|
i915_gem_object_update_fence(obj, reg, enable);
|
|
|
|
|
2012-04-17 21:31:30 +07:00
|
|
|
return 0;
|
2008-11-13 01:03:55 +07:00
|
|
|
}
|
|
|
|
|
2012-07-26 17:49:32 +07:00
|
|
|
static bool i915_gem_valid_gtt_space(struct drm_device *dev,
|
|
|
|
struct drm_mm_node *gtt_space,
|
|
|
|
unsigned long cache_level)
|
|
|
|
{
|
|
|
|
struct drm_mm_node *other;
|
|
|
|
|
|
|
|
/* On non-LLC machines we have to be careful when putting differing
|
|
|
|
* types of snoopable memory together to avoid the prefetcher
|
2012-12-03 23:26:16 +07:00
|
|
|
* crossing memory domains and dying.
|
2012-07-26 17:49:32 +07:00
|
|
|
*/
|
|
|
|
if (HAS_LLC(dev))
|
|
|
|
return true;
|
|
|
|
|
2013-07-06 04:41:06 +07:00
|
|
|
if (!drm_mm_node_allocated(gtt_space))
|
2012-07-26 17:49:32 +07:00
|
|
|
return true;
|
|
|
|
|
|
|
|
if (list_empty(>t_space->node_list))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
other = list_entry(gtt_space->node_list.prev, struct drm_mm_node, node_list);
|
|
|
|
if (other->allocated && !other->hole_follows && other->color != cache_level)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
other = list_entry(gtt_space->node_list.next, struct drm_mm_node, node_list);
|
|
|
|
if (other->allocated && !gtt_space->hole_follows && other->color != cache_level)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void i915_gem_verify_gtt(struct drm_device *dev)
|
|
|
|
{
|
|
|
|
#if WATCH_GTT
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
|
|
|
struct drm_i915_gem_object *obj;
|
|
|
|
int err = 0;
|
|
|
|
|
2013-06-01 01:28:48 +07:00
|
|
|
list_for_each_entry(obj, &dev_priv->mm.gtt_list, global_list) {
|
2012-07-26 17:49:32 +07:00
|
|
|
if (obj->gtt_space == NULL) {
|
|
|
|
printk(KERN_ERR "object found on GTT list with no space reserved\n");
|
|
|
|
err++;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (obj->cache_level != obj->gtt_space->color) {
|
|
|
|
printk(KERN_ERR "object reserved space [%08lx, %08lx] with wrong color, cache_level=%x, color=%lx\n",
|
2013-07-06 04:41:04 +07:00
|
|
|
i915_gem_obj_ggtt_offset(obj),
|
|
|
|
i915_gem_obj_ggtt_offset(obj) + i915_gem_obj_ggtt_size(obj),
|
2012-07-26 17:49:32 +07:00
|
|
|
obj->cache_level,
|
|
|
|
obj->gtt_space->color);
|
|
|
|
err++;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!i915_gem_valid_gtt_space(dev,
|
|
|
|
obj->gtt_space,
|
|
|
|
obj->cache_level)) {
|
|
|
|
printk(KERN_ERR "invalid GTT space found at [%08lx, %08lx] - color=%x\n",
|
2013-07-06 04:41:04 +07:00
|
|
|
i915_gem_obj_ggtt_offset(obj),
|
|
|
|
i915_gem_obj_ggtt_offset(obj) + i915_gem_obj_ggtt_size(obj),
|
2012-07-26 17:49:32 +07:00
|
|
|
obj->cache_level);
|
|
|
|
err++;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
WARN_ON(err);
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2008-07-31 02:06:12 +07:00
|
|
|
/**
|
|
|
|
* Finds free space in the GTT aperture and binds the object there.
|
|
|
|
*/
|
|
|
|
static int
|
drm/i915: plumb VM into bind/unbind code
As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).
This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.
> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-01 07:00:10 +07:00
|
|
|
i915_gem_object_bind_to_vm(struct drm_i915_gem_object *obj,
|
|
|
|
struct i915_address_space *vm,
|
|
|
|
unsigned alignment,
|
|
|
|
bool map_and_fenceable,
|
|
|
|
bool nonblocking)
|
2008-07-31 02:06:12 +07:00
|
|
|
{
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_device *dev = obj->base.dev;
|
2008-07-31 02:06:12 +07:00
|
|
|
drm_i915_private_t *dev_priv = dev->dev_private;
|
2010-11-15 04:32:36 +07:00
|
|
|
u32 size, fence_size, fence_alignment, unfenced_alignment;
|
drm/i915: plumb VM into bind/unbind code
As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).
This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.
> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-01 07:00:10 +07:00
|
|
|
size_t gtt_max =
|
|
|
|
map_and_fenceable ? dev_priv->gtt.mappable_end : vm->total;
|
2013-07-18 02:19:03 +07:00
|
|
|
struct i915_vma *vma;
|
2009-09-14 22:50:30 +07:00
|
|
|
int ret;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2011-07-19 03:11:49 +07:00
|
|
|
fence_size = i915_gem_get_gtt_size(dev,
|
|
|
|
obj->base.size,
|
|
|
|
obj->tiling_mode);
|
|
|
|
fence_alignment = i915_gem_get_gtt_alignment(dev,
|
|
|
|
obj->base.size,
|
2013-01-08 02:47:33 +07:00
|
|
|
obj->tiling_mode, true);
|
2011-07-19 03:11:49 +07:00
|
|
|
unfenced_alignment =
|
2013-01-08 02:47:33 +07:00
|
|
|
i915_gem_get_gtt_alignment(dev,
|
2011-07-19 03:11:49 +07:00
|
|
|
obj->base.size,
|
2013-01-08 02:47:33 +07:00
|
|
|
obj->tiling_mode, false);
|
2010-09-25 03:15:47 +07:00
|
|
|
|
2008-07-31 02:06:12 +07:00
|
|
|
if (alignment == 0)
|
2010-11-15 04:32:36 +07:00
|
|
|
alignment = map_and_fenceable ? fence_alignment :
|
|
|
|
unfenced_alignment;
|
2010-11-04 23:11:09 +07:00
|
|
|
if (map_and_fenceable && alignment & (fence_alignment - 1)) {
|
2008-07-31 02:06:12 +07:00
|
|
|
DRM_ERROR("Invalid object alignment requested %u\n", alignment);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
size = map_and_fenceable ? fence_size : obj->base.size;
|
2010-09-25 03:15:47 +07:00
|
|
|
|
2010-05-27 19:18:21 +07:00
|
|
|
/* If the object is bigger than the entire aperture, reject it early
|
|
|
|
* before evicting everything in a vain attempt to find space.
|
|
|
|
*/
|
2013-05-26 02:26:35 +07:00
|
|
|
if (obj->base.size > gtt_max) {
|
2013-06-07 20:03:50 +07:00
|
|
|
DRM_ERROR("Attempting to bind an object larger than the aperture: object=%zd > %s aperture=%zu\n",
|
2013-05-21 22:58:49 +07:00
|
|
|
obj->base.size,
|
|
|
|
map_and_fenceable ? "mappable" : "total",
|
2013-05-26 02:26:35 +07:00
|
|
|
gtt_max);
|
2010-05-27 19:18:21 +07:00
|
|
|
return -E2BIG;
|
|
|
|
}
|
|
|
|
|
2012-06-07 21:38:42 +07:00
|
|
|
ret = i915_gem_object_get_pages(obj);
|
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 16:40:46 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2012-11-20 17:45:16 +07:00
|
|
|
i915_gem_object_pin_pages(obj);
|
|
|
|
|
drm/i915: plumb VM into bind/unbind code
As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).
This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.
> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-01 07:00:10 +07:00
|
|
|
BUG_ON(!i915_is_ggtt(vm));
|
|
|
|
|
2013-08-14 16:38:35 +07:00
|
|
|
vma = i915_gem_obj_lookup_or_create_vma(obj, vm);
|
2013-07-19 12:45:46 +07:00
|
|
|
if (IS_ERR(vma)) {
|
2013-07-22 17:12:38 +07:00
|
|
|
ret = PTR_ERR(vma);
|
|
|
|
goto err_unpin;
|
2013-07-18 02:19:03 +07:00
|
|
|
}
|
|
|
|
|
2013-08-14 16:38:35 +07:00
|
|
|
/* For now we only ever use 1 vma per object */
|
|
|
|
WARN_ON(!list_is_singular(&obj->vma_list));
|
|
|
|
|
2013-05-26 02:26:35 +07:00
|
|
|
search_free:
|
drm/i915: plumb VM into bind/unbind code
As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).
This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.
> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-01 07:00:10 +07:00
|
|
|
ret = drm_mm_insert_node_in_range_generic(&vm->mm, &vma->node,
|
2013-05-26 02:26:35 +07:00
|
|
|
size, alignment,
|
2013-07-27 18:36:27 +07:00
|
|
|
obj->cache_level, 0, gtt_max,
|
|
|
|
DRM_MM_SEARCH_DEFAULT);
|
2012-12-08 03:37:07 +07:00
|
|
|
if (ret) {
|
2013-08-01 07:00:11 +07:00
|
|
|
ret = i915_gem_evict_something(dev, vm, size, alignment,
|
2012-07-26 17:49:32 +07:00
|
|
|
obj->cache_level,
|
2012-08-11 21:41:04 +07:00
|
|
|
map_and_fenceable,
|
|
|
|
nonblocking);
|
2012-12-08 03:37:07 +07:00
|
|
|
if (ret == 0)
|
|
|
|
goto search_free;
|
2009-09-21 06:22:34 +07:00
|
|
|
|
2013-07-22 17:12:38 +07:00
|
|
|
goto err_free_vma;
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
2013-07-18 02:19:03 +07:00
|
|
|
if (WARN_ON(!i915_gem_valid_gtt_space(dev, &vma->node,
|
2013-07-06 04:41:06 +07:00
|
|
|
obj->cache_level))) {
|
2013-07-18 02:19:03 +07:00
|
|
|
ret = -EINVAL;
|
2013-07-22 17:12:38 +07:00
|
|
|
goto err_remove_node;
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
2012-02-16 05:50:21 +07:00
|
|
|
ret = i915_gem_gtt_prepare_object(obj);
|
2013-07-18 02:19:03 +07:00
|
|
|
if (ret)
|
2013-07-22 17:12:38 +07:00
|
|
|
goto err_remove_node;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2013-06-01 01:28:48 +07:00
|
|
|
list_move_tail(&obj->global_list, &dev_priv->mm.bound_list);
|
2013-08-01 07:00:14 +07:00
|
|
|
list_add_tail(&vma->mm_list, &vm->inactive_list);
|
2010-08-07 17:01:20 +07:00
|
|
|
|
2013-08-14 08:09:07 +07:00
|
|
|
if (i915_is_ggtt(vm)) {
|
|
|
|
bool mappable, fenceable;
|
2010-09-25 03:15:47 +07:00
|
|
|
|
2013-08-14 15:21:23 +07:00
|
|
|
fenceable = (vma->node.size == fence_size &&
|
|
|
|
(vma->node.start & (fence_alignment - 1)) == 0);
|
2013-08-14 08:09:07 +07:00
|
|
|
|
2013-08-14 15:21:23 +07:00
|
|
|
mappable = (vma->node.start + obj->base.size <=
|
|
|
|
dev_priv->gtt.mappable_end);
|
2010-09-25 03:15:47 +07:00
|
|
|
|
2013-08-01 07:00:13 +07:00
|
|
|
obj->map_and_fenceable = mappable && fenceable;
|
2013-08-14 08:09:07 +07:00
|
|
|
}
|
2010-11-04 23:11:09 +07:00
|
|
|
|
2013-08-10 12:12:12 +07:00
|
|
|
WARN_ON(map_and_fenceable && !obj->map_and_fenceable);
|
2010-11-04 23:11:09 +07:00
|
|
|
|
drm/i915: plumb VM into bind/unbind code
As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).
This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.
> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-01 07:00:10 +07:00
|
|
|
trace_i915_vma_bind(vma, map_and_fenceable);
|
2012-07-26 17:49:32 +07:00
|
|
|
i915_gem_verify_gtt(dev);
|
2008-07-31 02:06:12 +07:00
|
|
|
return 0;
|
2013-07-18 02:19:03 +07:00
|
|
|
|
2013-07-22 17:12:38 +07:00
|
|
|
err_remove_node:
|
2013-07-19 12:46:27 +07:00
|
|
|
drm_mm_remove_node(&vma->node);
|
2013-07-22 17:12:38 +07:00
|
|
|
err_free_vma:
|
2013-07-18 02:19:03 +07:00
|
|
|
i915_gem_vma_destroy(vma);
|
2013-07-22 17:12:38 +07:00
|
|
|
err_unpin:
|
2013-07-18 02:19:03 +07:00
|
|
|
i915_gem_object_unpin_pages(obj);
|
|
|
|
return ret;
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
2013-08-08 20:41:09 +07:00
|
|
|
bool
|
2013-08-09 18:26:45 +07:00
|
|
|
i915_gem_clflush_object(struct drm_i915_gem_object *obj,
|
|
|
|
bool force)
|
2008-07-31 02:06:12 +07:00
|
|
|
{
|
|
|
|
/* If we don't have a page list set up, then we're not pinned
|
|
|
|
* to GPU, and we can ignore the cache flush because it'll happen
|
|
|
|
* again at bind time.
|
|
|
|
*/
|
2010-11-09 02:18:58 +07:00
|
|
|
if (obj->pages == NULL)
|
2013-08-08 20:41:09 +07:00
|
|
|
return false;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2013-02-14 02:56:05 +07:00
|
|
|
/*
|
|
|
|
* Stolen memory is always coherent with the GPU as it is explicitly
|
|
|
|
* marked as wc by the system, or the system is cache-coherent.
|
|
|
|
*/
|
|
|
|
if (obj->stolen)
|
2013-08-08 20:41:09 +07:00
|
|
|
return false;
|
2013-02-14 02:56:05 +07:00
|
|
|
|
2011-03-30 06:59:52 +07:00
|
|
|
/* If the GPU is snooping the contents of the CPU cache,
|
|
|
|
* we do not need to manually clear the CPU cache lines. However,
|
|
|
|
* the caches are only snooped when the render cache is
|
|
|
|
* flushed/invalidated. As we always have to emit invalidations
|
|
|
|
* and flushes when moving into and out of the RENDER domain, correct
|
|
|
|
* snooping behaviour occurs naturally as the result of our domain
|
|
|
|
* tracking.
|
|
|
|
*/
|
2013-08-09 18:26:45 +07:00
|
|
|
if (!force && cpu_cache_is_coherent(obj->base.dev, obj->cache_level))
|
2013-08-08 20:41:09 +07:00
|
|
|
return false;
|
2011-03-30 06:59:52 +07:00
|
|
|
|
2009-08-25 17:15:50 +07:00
|
|
|
trace_i915_gem_object_clflush(obj);
|
2012-06-01 21:20:22 +07:00
|
|
|
drm_clflush_sg(obj->pages);
|
2013-08-08 20:41:09 +07:00
|
|
|
|
|
|
|
return true;
|
2008-11-15 04:35:19 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/** Flushes the GTT write domain for the object if it's dirty. */
|
|
|
|
static void
|
2010-11-09 02:18:58 +07:00
|
|
|
i915_gem_object_flush_gtt_write_domain(struct drm_i915_gem_object *obj)
|
2008-11-15 04:35:19 +07:00
|
|
|
{
|
2009-08-25 17:15:50 +07:00
|
|
|
uint32_t old_write_domain;
|
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
if (obj->base.write_domain != I915_GEM_DOMAIN_GTT)
|
2008-11-15 04:35:19 +07:00
|
|
|
return;
|
|
|
|
|
2011-01-05 01:42:07 +07:00
|
|
|
/* No actual flushing is required for the GTT write domain. Writes
|
2008-11-15 04:35:19 +07:00
|
|
|
* to it immediately go to main memory as far as we know, so there's
|
|
|
|
* no chipset flush. It also doesn't land in render cache.
|
2011-01-05 01:42:07 +07:00
|
|
|
*
|
|
|
|
* However, we do have to enforce the order so that all writes through
|
|
|
|
* the GTT land before any writes to the device, such as updates to
|
|
|
|
* the GATT itself.
|
2008-11-15 04:35:19 +07:00
|
|
|
*/
|
2011-01-05 01:42:07 +07:00
|
|
|
wmb();
|
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
old_write_domain = obj->base.write_domain;
|
|
|
|
obj->base.write_domain = 0;
|
2009-08-25 17:15:50 +07:00
|
|
|
|
|
|
|
trace_i915_gem_object_change_domain(obj,
|
2010-11-09 02:18:58 +07:00
|
|
|
obj->base.read_domains,
|
2009-08-25 17:15:50 +07:00
|
|
|
old_write_domain);
|
2008-11-15 04:35:19 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/** Flushes the CPU write domain for the object if it's dirty. */
|
|
|
|
static void
|
2013-08-09 18:26:45 +07:00
|
|
|
i915_gem_object_flush_cpu_write_domain(struct drm_i915_gem_object *obj,
|
|
|
|
bool force)
|
2008-11-15 04:35:19 +07:00
|
|
|
{
|
2009-08-25 17:15:50 +07:00
|
|
|
uint32_t old_write_domain;
|
2008-11-15 04:35:19 +07:00
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
if (obj->base.write_domain != I915_GEM_DOMAIN_CPU)
|
2008-11-15 04:35:19 +07:00
|
|
|
return;
|
|
|
|
|
2013-08-08 20:41:09 +07:00
|
|
|
if (i915_gem_clflush_object(obj, force))
|
|
|
|
i915_gem_chipset_flush(obj->base.dev);
|
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
old_write_domain = obj->base.write_domain;
|
|
|
|
obj->base.write_domain = 0;
|
2009-08-25 17:15:50 +07:00
|
|
|
|
|
|
|
trace_i915_gem_object_change_domain(obj,
|
2010-11-09 02:18:58 +07:00
|
|
|
obj->base.read_domains,
|
2009-08-25 17:15:50 +07:00
|
|
|
old_write_domain);
|
2008-11-15 04:35:19 +07:00
|
|
|
}
|
|
|
|
|
2008-11-11 01:53:25 +07:00
|
|
|
/**
|
|
|
|
* Moves a single object to the GTT read, and possibly write domain.
|
|
|
|
*
|
|
|
|
* This function returns when the move is complete, including waiting on
|
|
|
|
* flushes to occur.
|
|
|
|
*/
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
int
|
2010-11-23 22:26:33 +07:00
|
|
|
i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj, bool write)
|
2008-11-11 01:53:25 +07:00
|
|
|
{
|
2012-04-24 21:52:35 +07:00
|
|
|
drm_i915_private_t *dev_priv = obj->base.dev->dev_private;
|
2009-08-25 17:15:50 +07:00
|
|
|
uint32_t old_write_domain, old_read_domains;
|
2008-11-15 04:35:19 +07:00
|
|
|
int ret;
|
2008-11-11 01:53:25 +07:00
|
|
|
|
2008-11-27 04:58:13 +07:00
|
|
|
/* Not valid to be called on unbound objects. */
|
2013-08-01 07:00:12 +07:00
|
|
|
if (!i915_gem_obj_bound_any(obj))
|
2008-11-27 04:58:13 +07:00
|
|
|
return -EINVAL;
|
|
|
|
|
2011-02-07 22:23:02 +07:00
|
|
|
if (obj->base.write_domain == I915_GEM_DOMAIN_GTT)
|
|
|
|
return 0;
|
|
|
|
|
2012-07-20 18:41:01 +07:00
|
|
|
ret = i915_gem_object_wait_rendering(obj, !write);
|
2011-01-08 00:09:48 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2013-08-09 18:26:45 +07:00
|
|
|
i915_gem_object_flush_cpu_write_domain(obj, false);
|
2009-08-25 17:15:50 +07:00
|
|
|
|
2012-10-10 01:24:37 +07:00
|
|
|
/* Serialise direct access to this object with the barriers for
|
|
|
|
* coherent writes from the GPU, by effectively invalidating the
|
|
|
|
* GTT domain upon first access.
|
|
|
|
*/
|
|
|
|
if ((obj->base.read_domains & I915_GEM_DOMAIN_GTT) == 0)
|
|
|
|
mb();
|
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
old_write_domain = obj->base.write_domain;
|
|
|
|
old_read_domains = obj->base.read_domains;
|
2009-08-25 17:15:50 +07:00
|
|
|
|
2008-11-15 04:35:19 +07:00
|
|
|
/* It should now be out of any other write domains, and we can update
|
|
|
|
* the domain values for our changes.
|
|
|
|
*/
|
2010-11-09 02:18:58 +07:00
|
|
|
BUG_ON((obj->base.write_domain & ~I915_GEM_DOMAIN_GTT) != 0);
|
|
|
|
obj->base.read_domains |= I915_GEM_DOMAIN_GTT;
|
2008-11-15 04:35:19 +07:00
|
|
|
if (write) {
|
2010-11-09 02:18:58 +07:00
|
|
|
obj->base.read_domains = I915_GEM_DOMAIN_GTT;
|
|
|
|
obj->base.write_domain = I915_GEM_DOMAIN_GTT;
|
|
|
|
obj->dirty = 1;
|
2008-11-11 01:53:25 +07:00
|
|
|
}
|
|
|
|
|
2009-08-25 17:15:50 +07:00
|
|
|
trace_i915_gem_object_change_domain(obj,
|
|
|
|
old_read_domains,
|
|
|
|
old_write_domain);
|
|
|
|
|
2012-04-24 21:52:35 +07:00
|
|
|
/* And bump the LRU for this access */
|
2013-08-01 07:00:14 +07:00
|
|
|
if (i915_gem_object_is_inactive(obj)) {
|
2013-09-24 23:57:57 +07:00
|
|
|
struct i915_vma *vma = i915_gem_obj_to_ggtt(obj);
|
2013-08-01 07:00:14 +07:00
|
|
|
if (vma)
|
|
|
|
list_move_tail(&vma->mm_list,
|
|
|
|
&dev_priv->gtt.base.inactive_list);
|
|
|
|
|
|
|
|
}
|
2012-04-24 21:52:35 +07:00
|
|
|
|
2008-11-15 04:35:19 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-04-04 15:44:39 +07:00
|
|
|
int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj,
|
|
|
|
enum i915_cache_level cache_level)
|
|
|
|
{
|
2012-02-09 23:15:47 +07:00
|
|
|
struct drm_device *dev = obj->base.dev;
|
|
|
|
drm_i915_private_t *dev_priv = dev->dev_private;
|
2013-08-01 07:00:03 +07:00
|
|
|
struct i915_vma *vma;
|
2011-04-04 15:44:39 +07:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (obj->cache_level == cache_level)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (obj->pin_count) {
|
|
|
|
DRM_DEBUG("can not change the cache level of pinned objects\n");
|
|
|
|
return -EBUSY;
|
|
|
|
}
|
|
|
|
|
2013-08-01 07:00:03 +07:00
|
|
|
list_for_each_entry(vma, &obj->vma_list, vma_link) {
|
|
|
|
if (!i915_gem_valid_gtt_space(dev, &vma->node, cache_level)) {
|
drm/i915: plumb VM into bind/unbind code
As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).
This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.
> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-01 07:00:10 +07:00
|
|
|
ret = i915_vma_unbind(vma);
|
2013-08-01 07:00:03 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
break;
|
|
|
|
}
|
2012-07-26 17:49:32 +07:00
|
|
|
}
|
|
|
|
|
2013-08-01 07:00:03 +07:00
|
|
|
if (i915_gem_obj_bound_any(obj)) {
|
2011-04-04 15:44:39 +07:00
|
|
|
ret = i915_gem_object_finish_gpu(obj);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
i915_gem_object_finish_gtt(obj);
|
|
|
|
|
|
|
|
/* Before SandyBridge, you could not use tiling or fence
|
|
|
|
* registers with snooped memory, so relinquish any fences
|
|
|
|
* currently pointing to our region in the aperture.
|
|
|
|
*/
|
2012-07-26 17:49:32 +07:00
|
|
|
if (INTEL_INFO(dev)->gen < 6) {
|
2011-04-04 15:44:39 +07:00
|
|
|
ret = i915_gem_object_put_fence(obj);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-02-16 05:50:22 +07:00
|
|
|
if (obj->has_global_gtt_mapping)
|
|
|
|
i915_gem_gtt_bind_object(obj, cache_level);
|
2012-02-09 23:15:47 +07:00
|
|
|
if (obj->has_aliasing_ppgtt_mapping)
|
|
|
|
i915_ppgtt_bind_object(dev_priv->mm.aliasing_ppgtt,
|
|
|
|
obj, cache_level);
|
2011-04-04 15:44:39 +07:00
|
|
|
}
|
|
|
|
|
2013-08-09 18:26:45 +07:00
|
|
|
list_for_each_entry(vma, &obj->vma_list, vma_link)
|
|
|
|
vma->node.color = cache_level;
|
|
|
|
obj->cache_level = cache_level;
|
|
|
|
|
|
|
|
if (cpu_write_needs_clflush(obj)) {
|
2011-04-04 15:44:39 +07:00
|
|
|
u32 old_read_domains, old_write_domain;
|
|
|
|
|
|
|
|
/* If we're coming from LLC cached, then we haven't
|
|
|
|
* actually been tracking whether the data is in the
|
|
|
|
* CPU cache or not, since we only allow one bit set
|
|
|
|
* in obj->write_domain and have been skipping the clflushes.
|
|
|
|
* Just set it to the CPU cache for now.
|
|
|
|
*/
|
|
|
|
WARN_ON(obj->base.write_domain & ~I915_GEM_DOMAIN_CPU);
|
|
|
|
|
|
|
|
old_read_domains = obj->base.read_domains;
|
|
|
|
old_write_domain = obj->base.write_domain;
|
|
|
|
|
|
|
|
obj->base.read_domains = I915_GEM_DOMAIN_CPU;
|
|
|
|
obj->base.write_domain = I915_GEM_DOMAIN_CPU;
|
|
|
|
|
|
|
|
trace_i915_gem_object_change_domain(obj,
|
|
|
|
old_read_domains,
|
|
|
|
old_write_domain);
|
|
|
|
}
|
|
|
|
|
2012-07-26 17:49:32 +07:00
|
|
|
i915_gem_verify_gtt(dev);
|
2011-04-04 15:44:39 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-09-22 07:01:20 +07:00
|
|
|
int i915_gem_get_caching_ioctl(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file)
|
2012-07-10 16:27:08 +07:00
|
|
|
{
|
2012-09-22 07:01:20 +07:00
|
|
|
struct drm_i915_gem_caching *args = data;
|
2012-07-10 16:27:08 +07:00
|
|
|
struct drm_i915_gem_object *obj;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = i915_mutex_lock_interruptible(dev);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
obj = to_intel_bo(drm_gem_object_lookup(dev, file, args->handle));
|
|
|
|
if (&obj->base == NULL) {
|
|
|
|
ret = -ENOENT;
|
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
|
2013-08-08 20:41:10 +07:00
|
|
|
switch (obj->cache_level) {
|
|
|
|
case I915_CACHE_LLC:
|
|
|
|
case I915_CACHE_L3_LLC:
|
|
|
|
args->caching = I915_CACHING_CACHED;
|
|
|
|
break;
|
|
|
|
|
2013-08-08 20:41:11 +07:00
|
|
|
case I915_CACHE_WT:
|
|
|
|
args->caching = I915_CACHING_DISPLAY;
|
|
|
|
break;
|
|
|
|
|
2013-08-08 20:41:10 +07:00
|
|
|
default:
|
|
|
|
args->caching = I915_CACHING_NONE;
|
|
|
|
break;
|
|
|
|
}
|
2012-07-10 16:27:08 +07:00
|
|
|
|
|
|
|
drm_gem_object_unreference(&obj->base);
|
|
|
|
unlock:
|
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-09-22 07:01:20 +07:00
|
|
|
int i915_gem_set_caching_ioctl(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file)
|
2012-07-10 16:27:08 +07:00
|
|
|
{
|
2012-09-22 07:01:20 +07:00
|
|
|
struct drm_i915_gem_caching *args = data;
|
2012-07-10 16:27:08 +07:00
|
|
|
struct drm_i915_gem_object *obj;
|
|
|
|
enum i915_cache_level level;
|
|
|
|
int ret;
|
|
|
|
|
2012-09-22 07:01:20 +07:00
|
|
|
switch (args->caching) {
|
|
|
|
case I915_CACHING_NONE:
|
2012-07-10 16:27:08 +07:00
|
|
|
level = I915_CACHE_NONE;
|
|
|
|
break;
|
2012-09-22 07:01:20 +07:00
|
|
|
case I915_CACHING_CACHED:
|
2012-07-10 16:27:08 +07:00
|
|
|
level = I915_CACHE_LLC;
|
|
|
|
break;
|
2013-08-08 20:41:11 +07:00
|
|
|
case I915_CACHING_DISPLAY:
|
|
|
|
level = HAS_WT(dev) ? I915_CACHE_WT : I915_CACHE_NONE;
|
|
|
|
break;
|
2012-07-10 16:27:08 +07:00
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2012-09-27 06:15:20 +07:00
|
|
|
ret = i915_mutex_lock_interruptible(dev);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2012-07-10 16:27:08 +07:00
|
|
|
obj = to_intel_bo(drm_gem_object_lookup(dev, file, args->handle));
|
|
|
|
if (&obj->base == NULL) {
|
|
|
|
ret = -ENOENT;
|
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = i915_gem_object_set_cache_level(obj, level);
|
|
|
|
|
|
|
|
drm_gem_object_unreference(&obj->base);
|
|
|
|
unlock:
|
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2013-08-09 18:25:09 +07:00
|
|
|
static bool is_pin_display(struct drm_i915_gem_object *obj)
|
|
|
|
{
|
|
|
|
/* There are 3 sources that pin objects:
|
|
|
|
* 1. The display engine (scanouts, sprites, cursors);
|
|
|
|
* 2. Reservations for execbuffer;
|
|
|
|
* 3. The user.
|
|
|
|
*
|
|
|
|
* We can ignore reservations as we hold the struct_mutex and
|
|
|
|
* are only called outside of the reservation path. The user
|
|
|
|
* can only increment pin_count once, and so if after
|
|
|
|
* subtracting the potential reference by the user, any pin_count
|
|
|
|
* remains, it must be due to another use by the display engine.
|
|
|
|
*/
|
|
|
|
return obj->pin_count - !!obj->user_pin_count;
|
|
|
|
}
|
|
|
|
|
2009-11-25 12:09:39 +07:00
|
|
|
/*
|
2011-04-14 15:41:17 +07:00
|
|
|
* Prepare buffer for display plane (scanout, cursors, etc).
|
|
|
|
* Can be called from an uninterruptible phase (modesetting) and allows
|
|
|
|
* any flushes to be pipelined (for pageflips).
|
2009-11-25 12:09:39 +07:00
|
|
|
*/
|
|
|
|
int
|
2011-04-14 15:41:17 +07:00
|
|
|
i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj,
|
|
|
|
u32 alignment,
|
2010-11-12 20:42:53 +07:00
|
|
|
struct intel_ring_buffer *pipelined)
|
2009-11-25 12:09:39 +07:00
|
|
|
{
|
2011-04-14 15:41:17 +07:00
|
|
|
u32 old_read_domains, old_write_domain;
|
2009-11-25 12:09:39 +07:00
|
|
|
int ret;
|
|
|
|
|
2010-12-06 21:36:27 +07:00
|
|
|
if (pipelined != obj->ring) {
|
2012-04-06 04:47:36 +07:00
|
|
|
ret = i915_gem_object_sync(obj, pipelined);
|
|
|
|
if (ret)
|
2009-11-25 12:09:39 +07:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2013-08-09 18:25:09 +07:00
|
|
|
/* Mark the pin_display early so that we account for the
|
|
|
|
* display coherency whilst setting up the cache domains.
|
|
|
|
*/
|
|
|
|
obj->pin_display = true;
|
|
|
|
|
2011-03-30 06:59:54 +07:00
|
|
|
/* The display engine is not coherent with the LLC cache on gen6. As
|
|
|
|
* a result, we make sure that the pinning that is about to occur is
|
|
|
|
* done with uncached PTEs. This is lowest common denominator for all
|
|
|
|
* chipsets.
|
|
|
|
*
|
|
|
|
* However for gen6+, we could do better by using the GFDT bit instead
|
|
|
|
* of uncaching, which would allow us to flush all the LLC-cached data
|
|
|
|
* with that bit in the PTE to main memory with just one PIPE_CONTROL.
|
|
|
|
*/
|
2013-08-08 20:41:10 +07:00
|
|
|
ret = i915_gem_object_set_cache_level(obj,
|
|
|
|
HAS_WT(obj->base.dev) ? I915_CACHE_WT : I915_CACHE_NONE);
|
2011-03-30 06:59:54 +07:00
|
|
|
if (ret)
|
2013-08-09 18:25:09 +07:00
|
|
|
goto err_unpin_display;
|
2011-03-30 06:59:54 +07:00
|
|
|
|
2011-04-14 15:41:17 +07:00
|
|
|
/* As the user may map the buffer once pinned in the display plane
|
|
|
|
* (e.g. libkms for the bootup splash), we have to ensure that we
|
|
|
|
* always use map_and_fenceable for all scanout buffers.
|
|
|
|
*/
|
2013-08-01 06:59:58 +07:00
|
|
|
ret = i915_gem_obj_ggtt_pin(obj, alignment, true, false);
|
2011-04-14 15:41:17 +07:00
|
|
|
if (ret)
|
2013-08-09 18:25:09 +07:00
|
|
|
goto err_unpin_display;
|
2011-04-14 15:41:17 +07:00
|
|
|
|
2013-08-09 18:26:45 +07:00
|
|
|
i915_gem_object_flush_cpu_write_domain(obj, true);
|
2010-05-27 19:18:14 +07:00
|
|
|
|
2011-04-14 15:41:17 +07:00
|
|
|
old_write_domain = obj->base.write_domain;
|
2010-11-09 02:18:58 +07:00
|
|
|
old_read_domains = obj->base.read_domains;
|
2011-04-14 15:41:17 +07:00
|
|
|
|
|
|
|
/* It should now be out of any other write domains, and we can update
|
|
|
|
* the domain values for our changes.
|
|
|
|
*/
|
2012-07-20 18:41:00 +07:00
|
|
|
obj->base.write_domain = 0;
|
2010-11-09 02:18:58 +07:00
|
|
|
obj->base.read_domains |= I915_GEM_DOMAIN_GTT;
|
2009-11-25 12:09:39 +07:00
|
|
|
|
|
|
|
trace_i915_gem_object_change_domain(obj,
|
|
|
|
old_read_domains,
|
2011-04-14 15:41:17 +07:00
|
|
|
old_write_domain);
|
2009-11-25 12:09:39 +07:00
|
|
|
|
|
|
|
return 0;
|
2013-08-09 18:25:09 +07:00
|
|
|
|
|
|
|
err_unpin_display:
|
|
|
|
obj->pin_display = is_pin_display(obj);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
i915_gem_object_unpin_from_display_plane(struct drm_i915_gem_object *obj)
|
|
|
|
{
|
|
|
|
i915_gem_object_unpin(obj);
|
|
|
|
obj->pin_display = is_pin_display(obj);
|
2009-11-25 12:09:39 +07:00
|
|
|
}
|
|
|
|
|
2010-11-13 16:49:11 +07:00
|
|
|
int
|
2011-04-14 04:04:09 +07:00
|
|
|
i915_gem_object_finish_gpu(struct drm_i915_gem_object *obj)
|
2010-11-13 16:49:11 +07:00
|
|
|
{
|
2011-01-08 00:09:48 +07:00
|
|
|
int ret;
|
|
|
|
|
2011-04-14 04:04:09 +07:00
|
|
|
if ((obj->base.read_domains & I915_GEM_GPU_DOMAINS) == 0)
|
2010-11-13 16:49:11 +07:00
|
|
|
return 0;
|
|
|
|
|
2012-07-20 18:41:01 +07:00
|
|
|
ret = i915_gem_object_wait_rendering(obj, false);
|
2011-12-14 19:57:23 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2011-04-14 04:04:09 +07:00
|
|
|
/* Ensure that we invalidate the GPU's caches and TLBs. */
|
|
|
|
obj->base.read_domains &= ~I915_GEM_GPU_DOMAINS;
|
2011-12-14 19:57:23 +07:00
|
|
|
return 0;
|
2010-11-13 16:49:11 +07:00
|
|
|
}
|
|
|
|
|
2008-11-15 04:35:19 +07:00
|
|
|
/**
|
|
|
|
* Moves a single object to the CPU read, and possibly write domain.
|
|
|
|
*
|
|
|
|
* This function returns when the move is complete, including waiting on
|
|
|
|
* flushes to occur.
|
|
|
|
*/
|
2012-03-26 15:10:27 +07:00
|
|
|
int
|
2010-11-12 20:42:53 +07:00
|
|
|
i915_gem_object_set_to_cpu_domain(struct drm_i915_gem_object *obj, bool write)
|
2008-11-15 04:35:19 +07:00
|
|
|
{
|
2009-08-25 17:15:50 +07:00
|
|
|
uint32_t old_write_domain, old_read_domains;
|
2008-11-15 04:35:19 +07:00
|
|
|
int ret;
|
|
|
|
|
2011-02-07 22:23:02 +07:00
|
|
|
if (obj->base.write_domain == I915_GEM_DOMAIN_CPU)
|
|
|
|
return 0;
|
|
|
|
|
2012-07-20 18:41:01 +07:00
|
|
|
ret = i915_gem_object_wait_rendering(obj, !write);
|
2011-01-08 00:09:48 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2008-11-15 04:35:19 +07:00
|
|
|
i915_gem_object_flush_gtt_write_domain(obj);
|
2008-11-11 01:53:25 +07:00
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
old_write_domain = obj->base.write_domain;
|
|
|
|
old_read_domains = obj->base.read_domains;
|
2009-08-25 17:15:50 +07:00
|
|
|
|
2008-11-15 04:35:19 +07:00
|
|
|
/* Flush the CPU cache if it's still invalid. */
|
2010-11-09 02:18:58 +07:00
|
|
|
if ((obj->base.read_domains & I915_GEM_DOMAIN_CPU) == 0) {
|
2013-08-09 18:26:45 +07:00
|
|
|
i915_gem_clflush_object(obj, false);
|
2008-11-11 01:53:25 +07:00
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
obj->base.read_domains |= I915_GEM_DOMAIN_CPU;
|
2008-11-11 01:53:25 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/* It should now be out of any other write domains, and we can update
|
|
|
|
* the domain values for our changes.
|
|
|
|
*/
|
2010-11-09 02:18:58 +07:00
|
|
|
BUG_ON((obj->base.write_domain & ~I915_GEM_DOMAIN_CPU) != 0);
|
2008-11-15 04:35:19 +07:00
|
|
|
|
|
|
|
/* If we're writing through the CPU, then the GPU read domains will
|
|
|
|
* need to be invalidated at next use.
|
|
|
|
*/
|
|
|
|
if (write) {
|
2010-11-09 02:18:58 +07:00
|
|
|
obj->base.read_domains = I915_GEM_DOMAIN_CPU;
|
|
|
|
obj->base.write_domain = I915_GEM_DOMAIN_CPU;
|
2008-11-15 04:35:19 +07:00
|
|
|
}
|
2008-11-11 01:53:25 +07:00
|
|
|
|
2009-08-25 17:15:50 +07:00
|
|
|
trace_i915_gem_object_change_domain(obj,
|
|
|
|
old_read_domains,
|
|
|
|
old_write_domain);
|
|
|
|
|
2008-11-11 01:53:25 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-07-31 02:06:12 +07:00
|
|
|
/* Throttle our rendering by waiting until the ring has completed our requests
|
|
|
|
* emitted over 20 msec ago.
|
|
|
|
*
|
2009-06-03 14:27:35 +07:00
|
|
|
* Note that if we were to use the current jiffies each time around the loop,
|
|
|
|
* we wouldn't escape the function with any frames outstanding if the time to
|
|
|
|
* render a frame was over 20ms.
|
|
|
|
*
|
2008-07-31 02:06:12 +07:00
|
|
|
* This should get us reasonable parallelism between CPU and GPU but also
|
|
|
|
* relatively low latency when blocking on a particular request to finish.
|
|
|
|
*/
|
2009-03-13 01:23:52 +07:00
|
|
|
static int
|
2010-09-24 22:02:42 +07:00
|
|
|
i915_gem_ring_throttle(struct drm_device *dev, struct drm_file *file)
|
2009-03-13 01:23:52 +07:00
|
|
|
{
|
2010-09-24 22:02:42 +07:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
|
|
|
struct drm_i915_file_private *file_priv = file->driver_priv;
|
2009-06-03 14:27:35 +07:00
|
|
|
unsigned long recent_enough = jiffies - msecs_to_jiffies(20);
|
2010-09-24 22:02:42 +07:00
|
|
|
struct drm_i915_gem_request *request;
|
|
|
|
struct intel_ring_buffer *ring = NULL;
|
drm/i915: create a race-free reset detection
With the previous patch the state transition handling of the reset
code itself is now (hopefully) race free and solid. But that still
leaves out everyone else - with the various lock-free wait paths
we have there's the possibility that the reset happens between the
point where we read the seqno we should wait on and the actual wait.
And if __wait_seqno then never sees the RESET_IN_PROGRESS state, we'll
happily wait for a seqno which will in all likelyhood never signal.
In practice this is not a big problem since the X server gets
constantly interrupted, and can then submit more work (hopefully) to
unblock everyone else: As soon as a new seqno write lands, all waiters
will unblock. But running the i-g-t reset testcase ZZ_hangman can
expose this race, especially on slower hw with fewer cpu cores.
Now looking forward to ARB_robustness and friends that's not the best
possible behaviour, hence this patch adds a reset_counter to be able
to detect any reset, even if a given thread never observed the
in-progress state.
The important part is to correctly order things:
- The write side needs to increment the counter after any seqno gets
reset. Hence we need to do that at the end of the reset work, and
again wake everyone up. We also need to place a barrier in between
any possible seqno changes and the counter increment, since any
unlock operations only guarantee that nothing leaks out, but not
that at later load operation gets moved ahead.
- On the read side we need to ensure that no reset can sneak in and
invalidate the seqno. In all cases we can use the one-sided barrier
that unlock operations guarantee (of the lock protecting the
respective seqno/ring pair) to ensure correct ordering. Hence it is
sufficient to place the atomic read before the mutex/spin_unlock and
no additional barriers are required.
The end-result of all this is that we need to wake up everyone twice
in a reset operation:
- First, before the reset starts, to get any lockholders of the locks,
so that the reset can proceed.
- Second, after the reset is completed, to allow waiters to properly
and reliably detect the reset condition and bail out.
I admit that this entire reset_counter thing smells a bit like
overkill, but I think it's justified since it makes it really explicit
what the bail-out condition is. And we need a reset counter anyway to
implement ARB_robustness, and imo with finer-grained locking on the
horizont this is the most resilient scheme I could think of.
v2: Drop spurious change in the wait_for_error EXIT_COND - we only
need to wait until we leave the reset-in-progress wedged state.
v3: Don't play tricks with barriers in the throttle ioctl, the
spin_unlock is barrier enough.
I've also considered using a little helper to grab the current
reset_counter, but then decided that hiding the atomic_read isn't a
great idea, since having it explicitly show up in the code is a nice
remainder to reviews to check the memory barriers.
v4: Add a comment to explain why we need to fall through in
__wait_seqno in the end variable assignments.
v5: Review from Damien:
- s/smb/smp/ in a comment
- don't increment the reset counter after we've set it to WEDGED. Now
we (again) properly wedge the gpu when the reset fails.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-06 15:01:42 +07:00
|
|
|
unsigned reset_counter;
|
2010-09-24 22:02:42 +07:00
|
|
|
u32 seqno = 0;
|
|
|
|
int ret;
|
2010-01-31 17:40:48 +07:00
|
|
|
|
2012-11-14 23:14:06 +07:00
|
|
|
ret = i915_gem_wait_for_error(&dev_priv->gpu_error);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ret = i915_gem_check_wedge(&dev_priv->gpu_error, false);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2011-01-26 22:39:14 +07:00
|
|
|
|
2010-09-26 17:03:27 +07:00
|
|
|
spin_lock(&file_priv->mm.lock);
|
2010-09-24 22:02:42 +07:00
|
|
|
list_for_each_entry(request, &file_priv->mm.request_list, client_list) {
|
2009-06-03 14:27:35 +07:00
|
|
|
if (time_after_eq(request->emitted_jiffies, recent_enough))
|
|
|
|
break;
|
2009-03-13 01:23:52 +07:00
|
|
|
|
2010-09-24 22:02:42 +07:00
|
|
|
ring = request->ring;
|
|
|
|
seqno = request->seqno;
|
2009-06-03 14:27:35 +07:00
|
|
|
}
|
drm/i915: create a race-free reset detection
With the previous patch the state transition handling of the reset
code itself is now (hopefully) race free and solid. But that still
leaves out everyone else - with the various lock-free wait paths
we have there's the possibility that the reset happens between the
point where we read the seqno we should wait on and the actual wait.
And if __wait_seqno then never sees the RESET_IN_PROGRESS state, we'll
happily wait for a seqno which will in all likelyhood never signal.
In practice this is not a big problem since the X server gets
constantly interrupted, and can then submit more work (hopefully) to
unblock everyone else: As soon as a new seqno write lands, all waiters
will unblock. But running the i-g-t reset testcase ZZ_hangman can
expose this race, especially on slower hw with fewer cpu cores.
Now looking forward to ARB_robustness and friends that's not the best
possible behaviour, hence this patch adds a reset_counter to be able
to detect any reset, even if a given thread never observed the
in-progress state.
The important part is to correctly order things:
- The write side needs to increment the counter after any seqno gets
reset. Hence we need to do that at the end of the reset work, and
again wake everyone up. We also need to place a barrier in between
any possible seqno changes and the counter increment, since any
unlock operations only guarantee that nothing leaks out, but not
that at later load operation gets moved ahead.
- On the read side we need to ensure that no reset can sneak in and
invalidate the seqno. In all cases we can use the one-sided barrier
that unlock operations guarantee (of the lock protecting the
respective seqno/ring pair) to ensure correct ordering. Hence it is
sufficient to place the atomic read before the mutex/spin_unlock and
no additional barriers are required.
The end-result of all this is that we need to wake up everyone twice
in a reset operation:
- First, before the reset starts, to get any lockholders of the locks,
so that the reset can proceed.
- Second, after the reset is completed, to allow waiters to properly
and reliably detect the reset condition and bail out.
I admit that this entire reset_counter thing smells a bit like
overkill, but I think it's justified since it makes it really explicit
what the bail-out condition is. And we need a reset counter anyway to
implement ARB_robustness, and imo with finer-grained locking on the
horizont this is the most resilient scheme I could think of.
v2: Drop spurious change in the wait_for_error EXIT_COND - we only
need to wait until we leave the reset-in-progress wedged state.
v3: Don't play tricks with barriers in the throttle ioctl, the
spin_unlock is barrier enough.
I've also considered using a little helper to grab the current
reset_counter, but then decided that hiding the atomic_read isn't a
great idea, since having it explicitly show up in the code is a nice
remainder to reviews to check the memory barriers.
v4: Add a comment to explain why we need to fall through in
__wait_seqno in the end variable assignments.
v5: Review from Damien:
- s/smb/smp/ in a comment
- don't increment the reset counter after we've set it to WEDGED. Now
we (again) properly wedge the gpu when the reset fails.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-06 15:01:42 +07:00
|
|
|
reset_counter = atomic_read(&dev_priv->gpu_error.reset_counter);
|
2010-09-26 17:03:27 +07:00
|
|
|
spin_unlock(&file_priv->mm.lock);
|
2009-03-13 01:23:52 +07:00
|
|
|
|
2010-09-24 22:02:42 +07:00
|
|
|
if (seqno == 0)
|
|
|
|
return 0;
|
2009-04-07 03:55:41 +07:00
|
|
|
|
drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-25 23:34:56 +07:00
|
|
|
ret = __wait_seqno(ring, seqno, reset_counter, true, NULL, NULL);
|
2010-09-24 22:02:42 +07:00
|
|
|
if (ret == 0)
|
|
|
|
queue_delayed_work(dev_priv->wq, &dev_priv->mm.retire_work, 0);
|
2009-03-13 01:23:52 +07:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2008-07-31 02:06:12 +07:00
|
|
|
int
|
2010-11-09 02:18:58 +07:00
|
|
|
i915_gem_object_pin(struct drm_i915_gem_object *obj,
|
2013-08-01 06:59:58 +07:00
|
|
|
struct i915_address_space *vm,
|
2010-11-09 02:18:58 +07:00
|
|
|
uint32_t alignment,
|
2012-08-11 21:41:04 +07:00
|
|
|
bool map_and_fenceable,
|
|
|
|
bool nonblocking)
|
2008-07-31 02:06:12 +07:00
|
|
|
{
|
drm/i915: plumb VM into bind/unbind code
As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).
This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.
> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-01 07:00:10 +07:00
|
|
|
struct i915_vma *vma;
|
2008-07-31 02:06:12 +07:00
|
|
|
int ret;
|
|
|
|
|
2012-09-15 15:41:57 +07:00
|
|
|
if (WARN_ON(obj->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT))
|
|
|
|
return -EBUSY;
|
2010-05-27 19:18:18 +07:00
|
|
|
|
drm/i915: plumb VM into bind/unbind code
As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).
This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.
> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-01 07:00:10 +07:00
|
|
|
WARN_ON(map_and_fenceable && !i915_is_ggtt(vm));
|
|
|
|
|
|
|
|
vma = i915_gem_obj_to_vma(obj, vm);
|
|
|
|
|
|
|
|
if (vma) {
|
|
|
|
if ((alignment &&
|
|
|
|
vma->node.start & (alignment - 1)) ||
|
2010-11-09 02:18:58 +07:00
|
|
|
(map_and_fenceable && !obj->map_and_fenceable)) {
|
|
|
|
WARN(obj->pin_count,
|
2010-08-04 18:37:41 +07:00
|
|
|
"bo is already pinned with incorrect alignment:"
|
2013-07-06 04:41:04 +07:00
|
|
|
" offset=%lx, req.alignment=%x, req.map_and_fenceable=%d,"
|
2010-11-04 23:11:09 +07:00
|
|
|
" obj->map_and_fenceable=%d\n",
|
drm/i915: plumb VM into bind/unbind code
As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).
This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.
> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-01 07:00:10 +07:00
|
|
|
i915_gem_obj_offset(obj, vm), alignment,
|
2010-11-04 23:11:09 +07:00
|
|
|
map_and_fenceable,
|
2010-11-09 02:18:58 +07:00
|
|
|
obj->map_and_fenceable);
|
drm/i915: plumb VM into bind/unbind code
As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).
This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.
> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-01 07:00:10 +07:00
|
|
|
ret = i915_vma_unbind(vma);
|
2010-05-27 19:18:18 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
drm/i915: plumb VM into bind/unbind code
As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).
This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.
> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-01 07:00:10 +07:00
|
|
|
if (!i915_gem_obj_bound(obj, vm)) {
|
2012-11-21 20:04:03 +07:00
|
|
|
struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
|
|
|
|
|
drm/i915: plumb VM into bind/unbind code
As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).
This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.
> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-01 07:00:10 +07:00
|
|
|
ret = i915_gem_object_bind_to_vm(obj, vm, alignment,
|
|
|
|
map_and_fenceable,
|
|
|
|
nonblocking);
|
2009-09-21 06:22:34 +07:00
|
|
|
if (ret)
|
2008-07-31 02:06:12 +07:00
|
|
|
return ret;
|
2012-11-21 20:04:03 +07:00
|
|
|
|
|
|
|
if (!dev_priv->mm.aliasing_ppgtt)
|
|
|
|
i915_gem_gtt_bind_object(obj, obj->cache_level);
|
2009-02-11 21:26:45 +07:00
|
|
|
}
|
2009-12-18 10:05:42 +07:00
|
|
|
|
2012-02-16 05:50:22 +07:00
|
|
|
if (!obj->has_global_gtt_mapping && map_and_fenceable)
|
|
|
|
i915_gem_gtt_bind_object(obj, obj->cache_level);
|
|
|
|
|
2012-04-24 21:47:30 +07:00
|
|
|
obj->pin_count++;
|
2010-11-24 19:23:44 +07:00
|
|
|
obj->pin_mappable |= map_and_fenceable;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
2010-11-09 02:18:58 +07:00
|
|
|
i915_gem_object_unpin(struct drm_i915_gem_object *obj)
|
2008-07-31 02:06:12 +07:00
|
|
|
{
|
2010-11-09 02:18:58 +07:00
|
|
|
BUG_ON(obj->pin_count == 0);
|
2013-08-01 07:00:12 +07:00
|
|
|
BUG_ON(!i915_gem_obj_bound_any(obj));
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2012-04-24 21:47:30 +07:00
|
|
|
if (--obj->pin_count == 0)
|
2010-11-24 19:23:44 +07:00
|
|
|
obj->pin_mappable = false;
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
i915_gem_pin_ioctl(struct drm_device *dev, void *data,
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_file *file)
|
2008-07-31 02:06:12 +07:00
|
|
|
{
|
|
|
|
struct drm_i915_gem_pin *args = data;
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_i915_gem_object *obj;
|
2008-07-31 02:06:12 +07:00
|
|
|
int ret;
|
|
|
|
|
2010-10-17 15:45:41 +07:00
|
|
|
ret = i915_mutex_lock_interruptible(dev);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
obj = to_intel_bo(drm_gem_object_lookup(dev, file, args->handle));
|
2011-02-19 18:31:06 +07:00
|
|
|
if (&obj->base == NULL) {
|
2010-10-17 15:45:41 +07:00
|
|
|
ret = -ENOENT;
|
|
|
|
goto unlock;
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
if (obj->madv != I915_MADV_WILLNEED) {
|
2009-09-22 20:24:13 +07:00
|
|
|
DRM_ERROR("Attempting to pin a purgeable buffer\n");
|
2010-10-17 15:45:41 +07:00
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
2009-09-14 22:50:29 +07:00
|
|
|
}
|
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
if (obj->pin_filp != NULL && obj->pin_filp != file) {
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
DRM_ERROR("Already pinned in i915_gem_pin_ioctl(): %d\n",
|
|
|
|
args->handle);
|
2010-10-17 15:45:41 +07:00
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
}
|
|
|
|
|
2013-10-10 19:46:37 +07:00
|
|
|
if (obj->user_pin_count == ULONG_MAX) {
|
|
|
|
ret = -EBUSY;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2013-01-02 17:31:22 +07:00
|
|
|
if (obj->user_pin_count == 0) {
|
2013-08-01 06:59:58 +07:00
|
|
|
ret = i915_gem_obj_ggtt_pin(obj, args->alignment, true, false);
|
2010-10-17 15:45:41 +07:00
|
|
|
if (ret)
|
|
|
|
goto out;
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
2013-01-02 17:31:22 +07:00
|
|
|
obj->user_pin_count++;
|
|
|
|
obj->pin_filp = file;
|
|
|
|
|
2013-07-06 04:41:04 +07:00
|
|
|
args->offset = i915_gem_obj_ggtt_offset(obj);
|
2010-10-17 15:45:41 +07:00
|
|
|
out:
|
2010-11-09 02:18:58 +07:00
|
|
|
drm_gem_object_unreference(&obj->base);
|
2010-10-17 15:45:41 +07:00
|
|
|
unlock:
|
2008-07-31 02:06:12 +07:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
2010-10-17 15:45:41 +07:00
|
|
|
return ret;
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
i915_gem_unpin_ioctl(struct drm_device *dev, void *data,
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_file *file)
|
2008-07-31 02:06:12 +07:00
|
|
|
{
|
|
|
|
struct drm_i915_gem_pin *args = data;
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_i915_gem_object *obj;
|
2010-09-25 17:22:51 +07:00
|
|
|
int ret;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2010-10-17 15:45:41 +07:00
|
|
|
ret = i915_mutex_lock_interruptible(dev);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
obj = to_intel_bo(drm_gem_object_lookup(dev, file, args->handle));
|
2011-02-19 18:31:06 +07:00
|
|
|
if (&obj->base == NULL) {
|
2010-10-17 15:45:41 +07:00
|
|
|
ret = -ENOENT;
|
|
|
|
goto unlock;
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
2010-09-25 17:22:51 +07:00
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
if (obj->pin_filp != file) {
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
DRM_ERROR("Not pinned by caller in i915_gem_pin_ioctl(): %d\n",
|
|
|
|
args->handle);
|
2010-10-17 15:45:41 +07:00
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
}
|
2010-11-09 02:18:58 +07:00
|
|
|
obj->user_pin_count--;
|
|
|
|
if (obj->user_pin_count == 0) {
|
|
|
|
obj->pin_filp = NULL;
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
i915_gem_object_unpin(obj);
|
|
|
|
}
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2010-10-17 15:45:41 +07:00
|
|
|
out:
|
2010-11-09 02:18:58 +07:00
|
|
|
drm_gem_object_unreference(&obj->base);
|
2010-10-17 15:45:41 +07:00
|
|
|
unlock:
|
2008-07-31 02:06:12 +07:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
2010-10-17 15:45:41 +07:00
|
|
|
return ret;
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
i915_gem_busy_ioctl(struct drm_device *dev, void *data,
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_file *file)
|
2008-07-31 02:06:12 +07:00
|
|
|
{
|
|
|
|
struct drm_i915_gem_busy *args = data;
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_i915_gem_object *obj;
|
2010-09-25 16:19:17 +07:00
|
|
|
int ret;
|
|
|
|
|
2010-09-25 17:22:51 +07:00
|
|
|
ret = i915_mutex_lock_interruptible(dev);
|
2010-10-17 15:45:41 +07:00
|
|
|
if (ret)
|
2010-09-25 17:22:51 +07:00
|
|
|
return ret;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
obj = to_intel_bo(drm_gem_object_lookup(dev, file, args->handle));
|
2011-02-19 18:31:06 +07:00
|
|
|
if (&obj->base == NULL) {
|
2010-10-17 15:45:41 +07:00
|
|
|
ret = -ENOENT;
|
|
|
|
goto unlock;
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
2010-05-21 08:08:57 +07:00
|
|
|
|
2010-08-04 21:36:30 +07:00
|
|
|
/* Count all active objects as busy, even if they are currently not used
|
|
|
|
* by the gpu. Users of this interface expect objects to eventually
|
|
|
|
* become non-busy without any further actions, therefore emit any
|
|
|
|
* necessary flushes here.
|
2008-12-15 10:05:04 +07:00
|
|
|
*/
|
2012-06-01 20:21:23 +07:00
|
|
|
ret = i915_gem_object_flush_active(obj);
|
2010-08-04 21:36:30 +07:00
|
|
|
|
2012-06-01 20:21:23 +07:00
|
|
|
args->busy = obj->active;
|
2012-07-04 18:25:08 +07:00
|
|
|
if (obj->ring) {
|
|
|
|
BUILD_BUG_ON(I915_NUM_RINGS > 16);
|
|
|
|
args->busy |= intel_ring_flag(obj->ring) << 16;
|
|
|
|
}
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
drm_gem_object_unreference(&obj->base);
|
2010-10-17 15:45:41 +07:00
|
|
|
unlock:
|
2008-07-31 02:06:12 +07:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
2010-10-17 15:45:41 +07:00
|
|
|
return ret;
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
i915_gem_throttle_ioctl(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file_priv)
|
|
|
|
{
|
2011-08-17 02:34:10 +07:00
|
|
|
return i915_gem_ring_throttle(dev, file_priv);
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
2009-09-14 22:50:29 +07:00
|
|
|
int
|
|
|
|
i915_gem_madvise_ioctl(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file_priv)
|
|
|
|
{
|
|
|
|
struct drm_i915_gem_madvise *args = data;
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_i915_gem_object *obj;
|
2010-09-25 17:22:51 +07:00
|
|
|
int ret;
|
2009-09-14 22:50:29 +07:00
|
|
|
|
|
|
|
switch (args->madv) {
|
|
|
|
case I915_MADV_DONTNEED:
|
|
|
|
case I915_MADV_WILLNEED:
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2010-10-17 15:45:41 +07:00
|
|
|
ret = i915_mutex_lock_interruptible(dev);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
obj = to_intel_bo(drm_gem_object_lookup(dev, file_priv, args->handle));
|
2011-02-19 18:31:06 +07:00
|
|
|
if (&obj->base == NULL) {
|
2010-10-17 15:45:41 +07:00
|
|
|
ret = -ENOENT;
|
|
|
|
goto unlock;
|
2009-09-14 22:50:29 +07:00
|
|
|
}
|
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
if (obj->pin_count) {
|
2010-10-17 15:45:41 +07:00
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
2009-09-14 22:50:29 +07:00
|
|
|
}
|
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
if (obj->madv != __I915_MADV_PURGED)
|
|
|
|
obj->madv = args->madv;
|
2009-09-14 22:50:29 +07:00
|
|
|
|
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 16:40:46 +07:00
|
|
|
/* if the object is no longer attached, discard its backing storage */
|
|
|
|
if (i915_gem_object_is_purgeable(obj) && obj->pages == NULL)
|
2009-09-21 05:13:10 +07:00
|
|
|
i915_gem_object_truncate(obj);
|
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
args->retained = obj->madv != __I915_MADV_PURGED;
|
2009-09-22 20:24:13 +07:00
|
|
|
|
2010-10-17 15:45:41 +07:00
|
|
|
out:
|
2010-11-09 02:18:58 +07:00
|
|
|
drm_gem_object_unreference(&obj->base);
|
2010-10-17 15:45:41 +07:00
|
|
|
unlock:
|
2009-09-14 22:50:29 +07:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
2010-10-17 15:45:41 +07:00
|
|
|
return ret;
|
2009-09-14 22:50:29 +07:00
|
|
|
}
|
|
|
|
|
2012-06-07 21:38:42 +07:00
|
|
|
void i915_gem_object_init(struct drm_i915_gem_object *obj,
|
|
|
|
const struct drm_i915_gem_object_ops *ops)
|
2012-08-11 21:41:06 +07:00
|
|
|
{
|
2013-06-01 01:28:48 +07:00
|
|
|
INIT_LIST_HEAD(&obj->global_list);
|
2012-08-11 21:41:06 +07:00
|
|
|
INIT_LIST_HEAD(&obj->ring_list);
|
2013-08-14 16:38:33 +07:00
|
|
|
INIT_LIST_HEAD(&obj->obj_exec_link);
|
2013-07-18 02:19:03 +07:00
|
|
|
INIT_LIST_HEAD(&obj->vma_list);
|
2012-08-11 21:41:06 +07:00
|
|
|
|
2012-06-07 21:38:42 +07:00
|
|
|
obj->ops = ops;
|
|
|
|
|
2012-08-11 21:41:06 +07:00
|
|
|
obj->fence_reg = I915_FENCE_REG_NONE;
|
|
|
|
obj->madv = I915_MADV_WILLNEED;
|
|
|
|
/* Avoid an unnecessary call to unbind on the first bind. */
|
|
|
|
obj->map_and_fenceable = true;
|
|
|
|
|
|
|
|
i915_gem_info_add_obj(obj->base.dev->dev_private, obj->base.size);
|
|
|
|
}
|
|
|
|
|
2012-06-07 21:38:42 +07:00
|
|
|
static const struct drm_i915_gem_object_ops i915_gem_object_ops = {
|
|
|
|
.get_pages = i915_gem_object_get_pages_gtt,
|
|
|
|
.put_pages = i915_gem_object_put_pages_gtt,
|
|
|
|
};
|
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_i915_gem_object *i915_gem_alloc_object(struct drm_device *dev,
|
|
|
|
size_t size)
|
2010-04-10 02:05:06 +07:00
|
|
|
{
|
2010-04-10 02:05:07 +07:00
|
|
|
struct drm_i915_gem_object *obj;
|
2011-06-28 06:18:18 +07:00
|
|
|
struct address_space *mapping;
|
2012-11-30 04:18:51 +07:00
|
|
|
gfp_t mask;
|
2010-04-10 02:05:06 +07:00
|
|
|
|
2012-11-15 18:32:30 +07:00
|
|
|
obj = i915_gem_object_alloc(dev);
|
2010-04-10 02:05:07 +07:00
|
|
|
if (obj == NULL)
|
|
|
|
return NULL;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2010-04-10 02:05:07 +07:00
|
|
|
if (drm_gem_object_init(dev, &obj->base, size) != 0) {
|
2012-11-15 18:32:30 +07:00
|
|
|
i915_gem_object_free(obj);
|
2010-04-10 02:05:07 +07:00
|
|
|
return NULL;
|
|
|
|
}
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2012-05-25 02:48:12 +07:00
|
|
|
mask = GFP_HIGHUSER | __GFP_RECLAIMABLE;
|
|
|
|
if (IS_CRESTLINE(dev) || IS_BROADWATER(dev)) {
|
|
|
|
/* 965gm cannot relocate objects above 4GiB. */
|
|
|
|
mask &= ~__GFP_HIGHMEM;
|
|
|
|
mask |= __GFP_DMA32;
|
|
|
|
}
|
|
|
|
|
2013-01-24 05:07:38 +07:00
|
|
|
mapping = file_inode(obj->base.filp)->i_mapping;
|
2012-05-25 02:48:12 +07:00
|
|
|
mapping_set_gfp_mask(mapping, mask);
|
2011-06-28 06:18:18 +07:00
|
|
|
|
2012-06-07 21:38:42 +07:00
|
|
|
i915_gem_object_init(obj, &i915_gem_object_ops);
|
2010-09-30 17:46:12 +07:00
|
|
|
|
2010-04-10 02:05:07 +07:00
|
|
|
obj->base.write_domain = I915_GEM_DOMAIN_CPU;
|
|
|
|
obj->base.read_domains = I915_GEM_DOMAIN_CPU;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2012-01-17 23:43:53 +07:00
|
|
|
if (HAS_LLC(dev)) {
|
|
|
|
/* On some devices, we can have the GPU use the LLC (the CPU
|
2011-03-30 06:59:55 +07:00
|
|
|
* cache) for about a 10% performance improvement
|
|
|
|
* compared to uncached. Graphics requests other than
|
|
|
|
* display scanout are coherent with the CPU in
|
|
|
|
* accessing this cache. This means in this mode we
|
|
|
|
* don't need to clflush on the CPU side, and on the
|
|
|
|
* GPU side we only need to flush internal caches to
|
|
|
|
* get data visible to the CPU.
|
|
|
|
*
|
|
|
|
* However, we maintain the display planes as UC, and so
|
|
|
|
* need to rebind when first used as such.
|
|
|
|
*/
|
|
|
|
obj->cache_level = I915_CACHE_LLC;
|
|
|
|
} else
|
|
|
|
obj->cache_level = I915_CACHE_NONE;
|
|
|
|
|
2013-07-25 04:25:03 +07:00
|
|
|
trace_i915_gem_object_create(obj);
|
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
return obj;
|
2010-04-10 02:05:07 +07:00
|
|
|
}
|
|
|
|
|
2012-04-24 21:47:31 +07:00
|
|
|
void i915_gem_free_object(struct drm_gem_object *gem_obj)
|
2008-07-31 02:06:12 +07:00
|
|
|
{
|
2012-04-24 21:47:31 +07:00
|
|
|
struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_device *dev = obj->base.dev;
|
2010-07-24 05:18:50 +07:00
|
|
|
drm_i915_private_t *dev_priv = dev->dev_private;
|
drm/i915: plumb VM into bind/unbind code
As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).
This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.
> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-01 07:00:10 +07:00
|
|
|
struct i915_vma *vma, *next;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2013-11-28 03:20:34 +07:00
|
|
|
intel_runtime_pm_get(dev_priv);
|
|
|
|
|
2011-03-20 18:20:19 +07:00
|
|
|
trace_i915_gem_object_destroy(obj);
|
|
|
|
|
2012-04-24 21:47:31 +07:00
|
|
|
if (obj->phys_obj)
|
|
|
|
i915_gem_detach_phys_object(dev, obj);
|
|
|
|
|
|
|
|
obj->pin_count = 0;
|
drm/i915: plumb VM into bind/unbind code
As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).
This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.
> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-01 07:00:10 +07:00
|
|
|
/* NB: 0 or 1 elements */
|
|
|
|
WARN_ON(!list_empty(&obj->vma_list) &&
|
|
|
|
!list_is_singular(&obj->vma_list));
|
|
|
|
list_for_each_entry_safe(vma, next, &obj->vma_list, vma_link) {
|
|
|
|
int ret = i915_vma_unbind(vma);
|
|
|
|
if (WARN_ON(ret == -ERESTARTSYS)) {
|
|
|
|
bool was_interruptible;
|
2012-04-24 21:47:31 +07:00
|
|
|
|
drm/i915: plumb VM into bind/unbind code
As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).
This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.
> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-01 07:00:10 +07:00
|
|
|
was_interruptible = dev_priv->mm.interruptible;
|
|
|
|
dev_priv->mm.interruptible = false;
|
2012-04-24 21:47:31 +07:00
|
|
|
|
drm/i915: plumb VM into bind/unbind code
As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).
This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.
> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-01 07:00:10 +07:00
|
|
|
WARN_ON(i915_vma_unbind(vma));
|
2012-04-24 21:47:31 +07:00
|
|
|
|
drm/i915: plumb VM into bind/unbind code
As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).
This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.
> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-01 07:00:10 +07:00
|
|
|
dev_priv->mm.interruptible = was_interruptible;
|
|
|
|
}
|
2012-04-24 21:47:31 +07:00
|
|
|
}
|
|
|
|
|
2013-06-01 04:46:20 +07:00
|
|
|
/* Stolen objects don't hold a ref, but do hold pin count. Fix that up
|
|
|
|
* before progressing. */
|
|
|
|
if (obj->stolen)
|
|
|
|
i915_gem_object_unpin_pages(obj);
|
|
|
|
|
2013-06-01 01:28:47 +07:00
|
|
|
if (WARN_ON(obj->pages_pin_count))
|
|
|
|
obj->pages_pin_count = 0;
|
2012-06-07 21:38:42 +07:00
|
|
|
i915_gem_object_put_pages(obj);
|
2012-08-11 21:41:03 +07:00
|
|
|
i915_gem_object_free_mmap_offset(obj);
|
2012-11-15 18:32:26 +07:00
|
|
|
i915_gem_object_release_stolen(obj);
|
2008-11-13 01:03:55 +07:00
|
|
|
|
2012-06-01 21:20:22 +07:00
|
|
|
BUG_ON(obj->pages);
|
|
|
|
|
2012-09-05 03:02:58 +07:00
|
|
|
if (obj->base.import_attach)
|
|
|
|
drm_prime_gem_destroy(&obj->base, NULL);
|
2008-11-13 01:03:55 +07:00
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
drm_gem_object_release(&obj->base);
|
|
|
|
i915_gem_info_remove_obj(dev_priv, obj->base.size);
|
2010-04-10 02:05:07 +07:00
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
kfree(obj->bit_17);
|
2012-11-15 18:32:30 +07:00
|
|
|
i915_gem_object_free(obj);
|
2013-11-28 03:20:34 +07:00
|
|
|
|
|
|
|
intel_runtime_pm_put(dev_priv);
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
2013-08-14 19:14:04 +07:00
|
|
|
struct i915_vma *i915_gem_obj_to_vma(struct drm_i915_gem_object *obj,
|
2013-07-18 02:19:03 +07:00
|
|
|
struct i915_address_space *vm)
|
2013-08-14 19:14:04 +07:00
|
|
|
{
|
|
|
|
struct i915_vma *vma;
|
|
|
|
list_for_each_entry(vma, &obj->vma_list, vma_link)
|
|
|
|
if (vma->vm == vm)
|
|
|
|
return vma;
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct i915_vma *__i915_gem_vma_create(struct drm_i915_gem_object *obj,
|
|
|
|
struct i915_address_space *vm)
|
2013-07-18 02:19:03 +07:00
|
|
|
{
|
|
|
|
struct i915_vma *vma = kzalloc(sizeof(*vma), GFP_KERNEL);
|
|
|
|
if (vma == NULL)
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
|
|
|
|
INIT_LIST_HEAD(&vma->vma_link);
|
2013-08-01 07:00:14 +07:00
|
|
|
INIT_LIST_HEAD(&vma->mm_list);
|
2013-08-14 16:38:34 +07:00
|
|
|
INIT_LIST_HEAD(&vma->exec_list);
|
2013-07-18 02:19:03 +07:00
|
|
|
vma->vm = vm;
|
|
|
|
vma->obj = obj;
|
|
|
|
|
2013-08-01 07:00:16 +07:00
|
|
|
/* Keep GGTT vmas first to make debug easier */
|
|
|
|
if (i915_is_ggtt(vm))
|
|
|
|
list_add(&vma->vma_link, &obj->vma_list);
|
|
|
|
else
|
|
|
|
list_add_tail(&vma->vma_link, &obj->vma_list);
|
|
|
|
|
2013-07-18 02:19:03 +07:00
|
|
|
return vma;
|
|
|
|
}
|
|
|
|
|
2013-08-14 19:14:04 +07:00
|
|
|
struct i915_vma *
|
|
|
|
i915_gem_obj_lookup_or_create_vma(struct drm_i915_gem_object *obj,
|
|
|
|
struct i915_address_space *vm)
|
|
|
|
{
|
|
|
|
struct i915_vma *vma;
|
|
|
|
|
|
|
|
vma = i915_gem_obj_to_vma(obj, vm);
|
|
|
|
if (!vma)
|
|
|
|
vma = __i915_gem_vma_create(obj, vm);
|
|
|
|
|
|
|
|
return vma;
|
|
|
|
}
|
|
|
|
|
2013-07-18 02:19:03 +07:00
|
|
|
void i915_gem_vma_destroy(struct i915_vma *vma)
|
|
|
|
{
|
|
|
|
WARN_ON(vma->node.allocated);
|
2013-08-20 18:56:40 +07:00
|
|
|
|
|
|
|
/* Keep the vma as a placeholder in the execbuffer reservation lists */
|
|
|
|
if (!list_empty(&vma->exec_list))
|
|
|
|
return;
|
|
|
|
|
2013-08-01 07:00:16 +07:00
|
|
|
list_del(&vma->vma_link);
|
2013-08-26 16:23:47 +07:00
|
|
|
|
2013-07-18 02:19:03 +07:00
|
|
|
kfree(vma);
|
|
|
|
}
|
|
|
|
|
2010-01-07 17:39:13 +07:00
|
|
|
int
|
2013-10-16 17:50:01 +07:00
|
|
|
i915_gem_suspend(struct drm_device *dev)
|
2010-01-07 17:39:13 +07:00
|
|
|
{
|
|
|
|
drm_i915_private_t *dev_priv = dev->dev_private;
|
2013-10-16 17:50:01 +07:00
|
|
|
int ret = 0;
|
2008-11-14 06:00:55 +07:00
|
|
|
|
2013-10-16 17:50:01 +07:00
|
|
|
mutex_lock(&dev->struct_mutex);
|
2013-09-14 05:57:04 +07:00
|
|
|
if (dev_priv->ums.mm_suspended)
|
2013-10-16 17:50:01 +07:00
|
|
|
goto err;
|
2008-11-14 06:00:55 +07:00
|
|
|
|
2012-04-27 06:02:58 +07:00
|
|
|
ret = i915_gpu_idle(dev);
|
2013-09-14 05:57:04 +07:00
|
|
|
if (ret)
|
2013-10-16 17:50:01 +07:00
|
|
|
goto err;
|
2013-09-14 05:57:04 +07:00
|
|
|
|
2012-04-27 06:02:58 +07:00
|
|
|
i915_gem_retire_requests(dev);
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2010-01-07 17:39:13 +07:00
|
|
|
/* Under UMS, be paranoid and evict. */
|
2012-04-25 00:22:52 +07:00
|
|
|
if (!drm_core_check_feature(dev, DRIVER_MODESET))
|
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 16:40:46 +07:00
|
|
|
i915_gem_evict_everything(dev);
|
2010-01-07 17:39:13 +07:00
|
|
|
|
|
|
|
i915_kernel_lost_context(dev);
|
2008-10-15 11:41:13 +07:00
|
|
|
i915_gem_cleanup_ringbuffer(dev);
|
2010-01-07 17:39:13 +07:00
|
|
|
|
2013-10-16 17:50:01 +07:00
|
|
|
/* Hack! Don't let anybody do execbuf while we don't control the chip.
|
|
|
|
* We need to replace this with a semaphore, or something.
|
|
|
|
* And not confound ums.mm_suspended!
|
|
|
|
*/
|
|
|
|
dev_priv->ums.mm_suspended = !drm_core_check_feature(dev,
|
|
|
|
DRIVER_MODESET);
|
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
|
|
|
|
del_timer_sync(&dev_priv->gpu_error.hangcheck_timer);
|
2010-01-07 17:39:13 +07:00
|
|
|
cancel_delayed_work_sync(&dev_priv->mm.retire_work);
|
drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-25 23:34:56 +07:00
|
|
|
cancel_delayed_work_sync(&dev_priv->mm.idle_work);
|
2010-01-07 17:39:13 +07:00
|
|
|
|
2008-07-31 02:06:12 +07:00
|
|
|
return 0;
|
2013-10-16 17:50:01 +07:00
|
|
|
|
|
|
|
err:
|
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
return ret;
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
2013-09-18 11:12:44 +07:00
|
|
|
int i915_gem_l3_remap(struct intel_ring_buffer *ring, int slice)
|
2012-05-26 06:56:24 +07:00
|
|
|
{
|
2013-09-18 11:12:44 +07:00
|
|
|
struct drm_device *dev = ring->dev;
|
2012-05-26 06:56:24 +07:00
|
|
|
drm_i915_private_t *dev_priv = dev->dev_private;
|
2013-09-20 01:13:41 +07:00
|
|
|
u32 reg_base = GEN7_L3LOG_BASE + (slice * 0x200);
|
|
|
|
u32 *remap_info = dev_priv->l3_parity.remap_info[slice];
|
2013-09-18 11:12:44 +07:00
|
|
|
int i, ret;
|
2012-05-26 06:56:24 +07:00
|
|
|
|
2013-09-20 01:01:40 +07:00
|
|
|
if (!HAS_L3_DPF(dev) || !remap_info)
|
2013-09-18 11:12:44 +07:00
|
|
|
return 0;
|
2012-05-26 06:56:24 +07:00
|
|
|
|
2013-09-18 11:12:44 +07:00
|
|
|
ret = intel_ring_begin(ring, GEN7_L3LOG_SIZE / 4 * 3);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2012-05-26 06:56:24 +07:00
|
|
|
|
2013-09-18 11:12:44 +07:00
|
|
|
/*
|
|
|
|
* Note: We do not worry about the concurrent register cacheline hang
|
|
|
|
* here because no other code should access these registers other than
|
|
|
|
* at initialization time.
|
|
|
|
*/
|
2012-05-26 06:56:24 +07:00
|
|
|
for (i = 0; i < GEN7_L3LOG_SIZE; i += 4) {
|
2013-09-18 11:12:44 +07:00
|
|
|
intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
|
|
|
|
intel_ring_emit(ring, reg_base + i);
|
|
|
|
intel_ring_emit(ring, remap_info[i/4]);
|
2012-05-26 06:56:24 +07:00
|
|
|
}
|
|
|
|
|
2013-09-18 11:12:44 +07:00
|
|
|
intel_ring_advance(ring);
|
2012-05-26 06:56:24 +07:00
|
|
|
|
2013-09-18 11:12:44 +07:00
|
|
|
return ret;
|
2012-05-26 06:56:24 +07:00
|
|
|
}
|
|
|
|
|
2012-02-02 15:58:12 +07:00
|
|
|
void i915_gem_init_swizzling(struct drm_device *dev)
|
|
|
|
{
|
|
|
|
drm_i915_private_t *dev_priv = dev->dev_private;
|
|
|
|
|
2012-01-31 22:47:55 +07:00
|
|
|
if (INTEL_INFO(dev)->gen < 5 ||
|
2012-02-02 15:58:12 +07:00
|
|
|
dev_priv->mm.bit_6_swizzle_x == I915_BIT_6_SWIZZLE_NONE)
|
|
|
|
return;
|
|
|
|
|
|
|
|
I915_WRITE(DISP_ARB_CTL, I915_READ(DISP_ARB_CTL) |
|
|
|
|
DISP_TILE_SURFACE_SWIZZLING);
|
|
|
|
|
2012-01-31 22:47:55 +07:00
|
|
|
if (IS_GEN5(dev))
|
|
|
|
return;
|
|
|
|
|
2012-02-02 15:58:12 +07:00
|
|
|
I915_WRITE(TILECTL, I915_READ(TILECTL) | TILECTL_SWZCTL);
|
|
|
|
if (IS_GEN6(dev))
|
2012-04-24 19:04:12 +07:00
|
|
|
I915_WRITE(ARB_MODE, _MASKED_BIT_ENABLE(ARB_MODE_SWIZZLE_SNB));
|
2012-12-19 01:31:23 +07:00
|
|
|
else if (IS_GEN7(dev))
|
2012-04-24 19:04:12 +07:00
|
|
|
I915_WRITE(ARB_MODE, _MASKED_BIT_ENABLE(ARB_MODE_SWIZZLE_IVB));
|
2013-11-03 11:07:04 +07:00
|
|
|
else if (IS_GEN8(dev))
|
|
|
|
I915_WRITE(GAMTARBMODE, _MASKED_BIT_ENABLE(ARB_MODE_SWIZZLE_BDW));
|
2012-12-19 01:31:23 +07:00
|
|
|
else
|
|
|
|
BUG();
|
2012-02-02 15:58:12 +07:00
|
|
|
}
|
2012-02-10 02:53:27 +07:00
|
|
|
|
2012-07-06 05:49:40 +07:00
|
|
|
static bool
|
|
|
|
intel_enable_blt(struct drm_device *dev)
|
|
|
|
{
|
|
|
|
if (!HAS_BLT(dev))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/* The blitter was dysfunctional on early prototypes */
|
|
|
|
if (IS_GEN6(dev) && dev->pdev->revision < 8) {
|
|
|
|
DRM_INFO("BLT not supported on this pre-production hardware;"
|
|
|
|
" graphics performance will be degraded.\n");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2013-02-09 02:49:24 +07:00
|
|
|
static int i915_gem_init_rings(struct drm_device *dev)
|
2010-05-21 08:08:55 +07:00
|
|
|
{
|
2013-02-09 02:49:24 +07:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2010-05-21 08:08:55 +07:00
|
|
|
int ret;
|
2010-05-27 19:18:22 +07:00
|
|
|
|
2010-09-16 09:43:11 +07:00
|
|
|
ret = intel_init_render_ring_buffer(dev);
|
2010-05-27 19:18:22 +07:00
|
|
|
if (ret)
|
2010-11-12 17:46:37 +07:00
|
|
|
return ret;
|
2010-05-27 19:18:22 +07:00
|
|
|
|
|
|
|
if (HAS_BSD(dev)) {
|
2010-09-16 09:43:11 +07:00
|
|
|
ret = intel_init_bsd_ring_buffer(dev);
|
2010-05-27 19:18:22 +07:00
|
|
|
if (ret)
|
|
|
|
goto cleanup_render_ring;
|
2010-05-21 08:08:57 +07:00
|
|
|
}
|
2010-05-27 19:18:22 +07:00
|
|
|
|
2012-07-06 05:49:40 +07:00
|
|
|
if (intel_enable_blt(dev)) {
|
2010-10-19 17:19:32 +07:00
|
|
|
ret = intel_init_blt_ring_buffer(dev);
|
|
|
|
if (ret)
|
|
|
|
goto cleanup_bsd_ring;
|
|
|
|
}
|
|
|
|
|
2013-05-29 09:22:23 +07:00
|
|
|
if (HAS_VEBOX(dev)) {
|
|
|
|
ret = intel_init_vebox_ring_buffer(dev);
|
|
|
|
if (ret)
|
|
|
|
goto cleanup_blt_ring;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2013-01-22 19:12:17 +07:00
|
|
|
ret = i915_gem_set_seqno(dev, ((u32)~0 - 0x1000));
|
2013-02-09 02:49:24 +07:00
|
|
|
if (ret)
|
2013-05-29 09:22:23 +07:00
|
|
|
goto cleanup_vebox_ring;
|
2013-02-09 02:49:24 +07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
2013-05-29 09:22:23 +07:00
|
|
|
cleanup_vebox_ring:
|
|
|
|
intel_cleanup_ring_buffer(&dev_priv->ring[VECS]);
|
2013-02-09 02:49:24 +07:00
|
|
|
cleanup_blt_ring:
|
|
|
|
intel_cleanup_ring_buffer(&dev_priv->ring[BCS]);
|
|
|
|
cleanup_bsd_ring:
|
|
|
|
intel_cleanup_ring_buffer(&dev_priv->ring[VCS]);
|
|
|
|
cleanup_render_ring:
|
|
|
|
intel_cleanup_ring_buffer(&dev_priv->ring[RCS]);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
i915_gem_init_hw(struct drm_device *dev)
|
|
|
|
{
|
|
|
|
drm_i915_private_t *dev_priv = dev->dev_private;
|
2013-09-20 01:13:41 +07:00
|
|
|
int ret, i;
|
2013-02-09 02:49:24 +07:00
|
|
|
|
|
|
|
if (INTEL_INFO(dev)->gen < 6 && !intel_enable_gtt())
|
|
|
|
return -EIO;
|
|
|
|
|
2013-07-05 01:02:05 +07:00
|
|
|
if (dev_priv->ellc_size)
|
2013-07-05 01:02:04 +07:00
|
|
|
I915_WRITE(HSW_IDICR, I915_READ(HSW_IDICR) | IDIHASHMSK(0xf));
|
2013-02-09 02:49:24 +07:00
|
|
|
|
2013-08-29 02:45:46 +07:00
|
|
|
if (IS_HSW_GT3(dev))
|
|
|
|
I915_WRITE(MI_PREDICATE_RESULT_2, LOWER_SLICE_ENABLED);
|
|
|
|
else
|
|
|
|
I915_WRITE(MI_PREDICATE_RESULT_2, LOWER_SLICE_DISABLED);
|
|
|
|
|
2013-04-06 03:12:43 +07:00
|
|
|
if (HAS_PCH_NOP(dev)) {
|
|
|
|
u32 temp = I915_READ(GEN7_MSG_CTL);
|
|
|
|
temp &= ~(WAIT_FOR_PCH_FLR_ACK | WAIT_FOR_PCH_RESET_ACK);
|
|
|
|
I915_WRITE(GEN7_MSG_CTL, temp);
|
|
|
|
}
|
|
|
|
|
2013-02-09 02:49:24 +07:00
|
|
|
i915_gem_init_swizzling(dev);
|
|
|
|
|
|
|
|
ret = i915_gem_init_rings(dev);
|
2013-01-22 19:12:17 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2013-09-18 11:12:44 +07:00
|
|
|
for (i = 0; i < NUM_L3_SLICES(dev); i++)
|
|
|
|
i915_gem_l3_remap(&dev_priv->ring[RCS], i);
|
|
|
|
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 04:42:42 +07:00
|
|
|
/*
|
|
|
|
* XXX: There was some w/a described somewhere suggesting loading
|
|
|
|
* contexts before PPGTT.
|
|
|
|
*/
|
2013-11-06 22:56:29 +07:00
|
|
|
ret = i915_gem_context_init(dev);
|
|
|
|
if (ret) {
|
|
|
|
i915_gem_cleanup_ringbuffer(dev);
|
|
|
|
DRM_ERROR("Context initialization failed %d\n", ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2013-04-09 08:43:56 +07:00
|
|
|
if (dev_priv->mm.aliasing_ppgtt) {
|
|
|
|
ret = dev_priv->mm.aliasing_ppgtt->enable(dev);
|
|
|
|
if (ret) {
|
|
|
|
i915_gem_cleanup_aliasing_ppgtt(dev);
|
|
|
|
DRM_INFO("PPGTT enable failed. This is not fatal, but unexpected\n");
|
|
|
|
}
|
|
|
|
}
|
2012-02-10 02:53:27 +07:00
|
|
|
|
2010-05-27 19:18:22 +07:00
|
|
|
return 0;
|
2010-05-21 08:08:55 +07:00
|
|
|
}
|
|
|
|
|
2012-04-24 21:47:41 +07:00
|
|
|
int i915_gem_init(struct drm_device *dev)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
mutex_lock(&dev->struct_mutex);
|
2013-03-09 01:45:53 +07:00
|
|
|
|
|
|
|
if (IS_VALLEYVIEW(dev)) {
|
|
|
|
/* VLVA0 (potential hack), BIOS isn't actually waking us */
|
|
|
|
I915_WRITE(VLV_GTLC_WAKE_CTRL, 1);
|
|
|
|
if (wait_for((I915_READ(VLV_GTLC_PW_STATUS) & 1) == 1, 10))
|
|
|
|
DRM_DEBUG_DRIVER("allow wake ack timed out\n");
|
|
|
|
}
|
|
|
|
|
2012-12-19 01:31:25 +07:00
|
|
|
i915_gem_init_global_gtt(dev);
|
2013-03-09 01:45:53 +07:00
|
|
|
|
2012-04-24 21:47:41 +07:00
|
|
|
ret = i915_gem_init_hw(dev);
|
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
if (ret) {
|
|
|
|
i915_gem_cleanup_aliasing_ppgtt(dev);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-04-27 04:28:03 +07:00
|
|
|
/* Allow hardware batchbuffers unless told otherwise, but not for KMS. */
|
|
|
|
if (!drm_core_check_feature(dev, DRIVER_MODESET))
|
|
|
|
dev_priv->dri1.allow_batchbuffer = 1;
|
2012-04-24 21:47:41 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-05-21 08:08:55 +07:00
|
|
|
void
|
|
|
|
i915_gem_cleanup_ringbuffer(struct drm_device *dev)
|
|
|
|
{
|
|
|
|
drm_i915_private_t *dev_priv = dev->dev_private;
|
2012-05-11 20:29:30 +07:00
|
|
|
struct intel_ring_buffer *ring;
|
2010-12-04 18:30:53 +07:00
|
|
|
int i;
|
2010-05-21 08:08:55 +07:00
|
|
|
|
2012-05-11 20:29:30 +07:00
|
|
|
for_each_ring(ring, dev_priv, i)
|
|
|
|
intel_cleanup_ring_buffer(ring);
|
2010-05-21 08:08:55 +07:00
|
|
|
}
|
|
|
|
|
2008-07-31 02:06:12 +07:00
|
|
|
int
|
|
|
|
i915_gem_entervt_ioctl(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file_priv)
|
|
|
|
{
|
2013-07-09 21:51:37 +07:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2012-05-11 20:29:30 +07:00
|
|
|
int ret;
|
2008-07-31 02:06:12 +07:00
|
|
|
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
if (drm_core_check_feature(dev, DRIVER_MODESET))
|
|
|
|
return 0;
|
|
|
|
|
2012-11-15 23:17:22 +07:00
|
|
|
if (i915_reset_in_progress(&dev_priv->gpu_error)) {
|
2008-07-31 02:06:12 +07:00
|
|
|
DRM_ERROR("Reenabling wedged hardware, good luck\n");
|
2012-11-15 23:17:22 +07:00
|
|
|
atomic_set(&dev_priv->gpu_error.reset_counter, 0);
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
mutex_lock(&dev->struct_mutex);
|
2013-07-09 21:51:37 +07:00
|
|
|
dev_priv->ums.mm_suspended = 0;
|
2008-12-24 09:42:32 +07:00
|
|
|
|
2012-02-02 15:58:12 +07:00
|
|
|
ret = i915_gem_init_hw(dev);
|
2009-04-18 09:43:32 +07:00
|
|
|
if (ret != 0) {
|
|
|
|
mutex_unlock(&dev->struct_mutex);
|
2008-12-24 09:42:32 +07:00
|
|
|
return ret;
|
2009-04-18 09:43:32 +07:00
|
|
|
}
|
2008-12-24 09:42:32 +07:00
|
|
|
|
2013-07-17 06:50:08 +07:00
|
|
|
BUG_ON(!list_empty(&dev_priv->gtt.base.active_list));
|
2008-07-31 02:06:12 +07:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
2008-08-20 22:04:27 +07:00
|
|
|
|
2010-06-07 20:03:03 +07:00
|
|
|
ret = drm_irq_install(dev);
|
|
|
|
if (ret)
|
|
|
|
goto cleanup_ringbuffer;
|
2008-08-20 22:04:27 +07:00
|
|
|
|
2008-07-31 02:06:12 +07:00
|
|
|
return 0;
|
2010-06-07 20:03:03 +07:00
|
|
|
|
|
|
|
cleanup_ringbuffer:
|
|
|
|
mutex_lock(&dev->struct_mutex);
|
|
|
|
i915_gem_cleanup_ringbuffer(dev);
|
2013-07-09 21:51:37 +07:00
|
|
|
dev_priv->ums.mm_suspended = 1;
|
2010-06-07 20:03:03 +07:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
|
|
|
|
return ret;
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
i915_gem_leavevt_ioctl(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file_priv)
|
|
|
|
{
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
if (drm_core_check_feature(dev, DRIVER_MODESET))
|
|
|
|
return 0;
|
|
|
|
|
2008-08-20 22:04:27 +07:00
|
|
|
drm_irq_uninstall(dev);
|
2013-07-09 21:51:37 +07:00
|
|
|
|
2013-10-16 17:50:01 +07:00
|
|
|
return i915_gem_suspend(dev);
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
i915_gem_lastclose(struct drm_device *dev)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2009-01-23 00:56:58 +07:00
|
|
|
if (drm_core_check_feature(dev, DRIVER_MODESET))
|
|
|
|
return;
|
|
|
|
|
2013-10-16 17:50:01 +07:00
|
|
|
ret = i915_gem_suspend(dev);
|
2008-10-15 11:41:13 +07:00
|
|
|
if (ret)
|
|
|
|
DRM_ERROR("failed to idle hardware: %d\n", ret);
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
|
|
|
|
2010-10-24 18:38:05 +07:00
|
|
|
static void
|
|
|
|
init_ring_lists(struct intel_ring_buffer *ring)
|
|
|
|
{
|
|
|
|
INIT_LIST_HEAD(&ring->active_list);
|
|
|
|
INIT_LIST_HEAD(&ring->request_list);
|
|
|
|
}
|
|
|
|
|
2013-08-01 06:59:54 +07:00
|
|
|
static void i915_init_vm(struct drm_i915_private *dev_priv,
|
|
|
|
struct i915_address_space *vm)
|
|
|
|
{
|
|
|
|
vm->dev = dev_priv->dev;
|
|
|
|
INIT_LIST_HEAD(&vm->active_list);
|
|
|
|
INIT_LIST_HEAD(&vm->inactive_list);
|
|
|
|
INIT_LIST_HEAD(&vm->global_link);
|
|
|
|
list_add(&vm->global_link, &dev_priv->vm_list);
|
|
|
|
}
|
|
|
|
|
2008-07-31 02:06:12 +07:00
|
|
|
void
|
|
|
|
i915_gem_load(struct drm_device *dev)
|
|
|
|
{
|
|
|
|
drm_i915_private_t *dev_priv = dev->dev_private;
|
2012-11-15 18:32:30 +07:00
|
|
|
int i;
|
|
|
|
|
|
|
|
dev_priv->slab =
|
|
|
|
kmem_cache_create("i915_gem_object",
|
|
|
|
sizeof(struct drm_i915_gem_object), 0,
|
|
|
|
SLAB_HWCACHE_ALIGN,
|
|
|
|
NULL);
|
2008-07-31 02:06:12 +07:00
|
|
|
|
2013-08-01 06:59:54 +07:00
|
|
|
INIT_LIST_HEAD(&dev_priv->vm_list);
|
|
|
|
i915_init_vm(dev_priv, &dev_priv->gtt.base);
|
|
|
|
|
2013-09-18 11:12:45 +07:00
|
|
|
INIT_LIST_HEAD(&dev_priv->context_list);
|
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 16:40:46 +07:00
|
|
|
INIT_LIST_HEAD(&dev_priv->mm.unbound_list);
|
|
|
|
INIT_LIST_HEAD(&dev_priv->mm.bound_list);
|
2009-08-30 02:49:51 +07:00
|
|
|
INIT_LIST_HEAD(&dev_priv->mm.fence_list);
|
2010-12-04 18:30:53 +07:00
|
|
|
for (i = 0; i < I915_NUM_RINGS; i++)
|
|
|
|
init_ring_lists(&dev_priv->ring[i]);
|
2011-10-10 02:52:02 +07:00
|
|
|
for (i = 0; i < I915_MAX_NUM_FENCES; i++)
|
2010-04-28 16:02:31 +07:00
|
|
|
INIT_LIST_HEAD(&dev_priv->fence_regs[i].lru_list);
|
2008-07-31 02:06:12 +07:00
|
|
|
INIT_DELAYED_WORK(&dev_priv->mm.retire_work,
|
|
|
|
i915_gem_retire_work_handler);
|
drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-25 23:34:56 +07:00
|
|
|
INIT_DELAYED_WORK(&dev_priv->mm.idle_work,
|
|
|
|
i915_gem_idle_work_handler);
|
2012-11-15 23:17:22 +07:00
|
|
|
init_waitqueue_head(&dev_priv->gpu_error.reset_queue);
|
2009-09-14 22:50:28 +07:00
|
|
|
|
2010-07-20 10:15:31 +07:00
|
|
|
/* On GEN3 we really need to make sure the ARB C3 LP bit is set */
|
|
|
|
if (IS_GEN3(dev)) {
|
2012-04-27 03:02:54 +07:00
|
|
|
I915_WRITE(MI_ARB_STATE,
|
|
|
|
_MASKED_BIT_ENABLE(MI_ARB_C3_LP_WRITE_ENABLE));
|
2010-07-20 10:15:31 +07:00
|
|
|
}
|
|
|
|
|
2010-12-19 18:42:05 +07:00
|
|
|
dev_priv->relative_constants_mode = I915_EXEC_CONSTANTS_REL_GENERAL;
|
|
|
|
|
2008-11-13 01:03:55 +07:00
|
|
|
/* Old X drivers will take 0-2 for front, back, depth buffers */
|
2010-01-27 00:43:10 +07:00
|
|
|
if (!drm_core_check_feature(dev, DRIVER_MODESET))
|
|
|
|
dev_priv->fence_reg_start = 3;
|
2008-11-13 01:03:55 +07:00
|
|
|
|
2013-04-09 17:02:47 +07:00
|
|
|
if (INTEL_INFO(dev)->gen >= 7 && !IS_VALLEYVIEW(dev))
|
|
|
|
dev_priv->num_fence_regs = 32;
|
|
|
|
else if (INTEL_INFO(dev)->gen >= 4 || IS_I945G(dev) || IS_I945GM(dev) || IS_G33(dev))
|
2008-11-13 01:03:55 +07:00
|
|
|
dev_priv->num_fence_regs = 16;
|
|
|
|
else
|
|
|
|
dev_priv->num_fence_regs = 8;
|
|
|
|
|
2009-06-23 20:41:02 +07:00
|
|
|
/* Initialize fence registers to zero */
|
2013-06-12 16:15:12 +07:00
|
|
|
INIT_LIST_HEAD(&dev_priv->mm.fence_list);
|
|
|
|
i915_gem_restore_fences(dev);
|
2011-05-07 03:53:49 +07:00
|
|
|
|
2008-07-31 02:06:12 +07:00
|
|
|
i915_gem_detect_bit_6_swizzle(dev);
|
2009-11-18 23:25:18 +07:00
|
|
|
init_waitqueue_head(&dev_priv->pending_flip_queue);
|
2010-10-28 18:51:39 +07:00
|
|
|
|
2011-02-21 21:43:56 +07:00
|
|
|
dev_priv->mm.interruptible = true;
|
|
|
|
|
drivers: convert shrinkers to new count/scan API
Convert the driver shrinkers to the new API. Most changes are compile
tested only because I either don't have the hardware or it's staging
stuff.
FWIW, the md and android code is pretty good, but the rest of it makes me
want to claw my eyes out. The amount of broken code I just encountered is
mind boggling. I've added comments explaining what is broken, but I fear
that some of the code would be best dealt with by being dragged behind the
bike shed, burying in mud up to it's neck and then run over repeatedly
with a blunt lawn mower.
Special mention goes to the zcache/zcache2 drivers. They can't co-exist
in the build at the same time, they are under different menu options in
menuconfig, they only show up when you've got the right set of mm
subsystem options configured and so even compile testing is an exercise in
pulling teeth. And that doesn't even take into account the horrible,
broken code...
[glommer@openvz.org: fixes for i915, android lowmem, zcache, bcache]
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Glauber Costa <glommer@openvz.org>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Rientjes <rientjes@google.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: J. Bruce Fields <bfields@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-28 07:18:11 +07:00
|
|
|
dev_priv->mm.inactive_shrinker.scan_objects = i915_gem_inactive_scan;
|
|
|
|
dev_priv->mm.inactive_shrinker.count_objects = i915_gem_inactive_count;
|
2010-10-28 18:51:39 +07:00
|
|
|
dev_priv->mm.inactive_shrinker.seeks = DEFAULT_SEEKS;
|
|
|
|
register_shrinker(&dev_priv->mm.inactive_shrinker);
|
2008-07-31 02:06:12 +07:00
|
|
|
}
|
2008-12-30 17:31:46 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Create a physically contiguous memory object for this object
|
|
|
|
* e.g. for cursor + overlay regs
|
|
|
|
*/
|
2010-08-20 19:23:26 +07:00
|
|
|
static int i915_gem_init_phys_object(struct drm_device *dev,
|
|
|
|
int id, int size, int align)
|
2008-12-30 17:31:46 +07:00
|
|
|
{
|
|
|
|
drm_i915_private_t *dev_priv = dev->dev_private;
|
|
|
|
struct drm_i915_gem_phys_object *phys_obj;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (dev_priv->mm.phys_objs[id - 1] || !size)
|
|
|
|
return 0;
|
|
|
|
|
2013-09-19 17:18:32 +07:00
|
|
|
phys_obj = kzalloc(sizeof(*phys_obj), GFP_KERNEL);
|
2008-12-30 17:31:46 +07:00
|
|
|
if (!phys_obj)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
phys_obj->id = id;
|
|
|
|
|
2010-08-07 17:01:39 +07:00
|
|
|
phys_obj->handle = drm_pci_alloc(dev, size, align);
|
2008-12-30 17:31:46 +07:00
|
|
|
if (!phys_obj->handle) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto kfree_obj;
|
|
|
|
}
|
|
|
|
#ifdef CONFIG_X86
|
|
|
|
set_memory_wc((unsigned long)phys_obj->handle->vaddr, phys_obj->handle->size / PAGE_SIZE);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
dev_priv->mm.phys_objs[id - 1] = phys_obj;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
kfree_obj:
|
2009-03-25 02:23:04 +07:00
|
|
|
kfree(phys_obj);
|
2008-12-30 17:31:46 +07:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2010-08-20 19:23:26 +07:00
|
|
|
static void i915_gem_free_phys_object(struct drm_device *dev, int id)
|
2008-12-30 17:31:46 +07:00
|
|
|
{
|
|
|
|
drm_i915_private_t *dev_priv = dev->dev_private;
|
|
|
|
struct drm_i915_gem_phys_object *phys_obj;
|
|
|
|
|
|
|
|
if (!dev_priv->mm.phys_objs[id - 1])
|
|
|
|
return;
|
|
|
|
|
|
|
|
phys_obj = dev_priv->mm.phys_objs[id - 1];
|
|
|
|
if (phys_obj->cur_obj) {
|
|
|
|
i915_gem_detach_phys_object(dev, phys_obj->cur_obj);
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef CONFIG_X86
|
|
|
|
set_memory_wb((unsigned long)phys_obj->handle->vaddr, phys_obj->handle->size / PAGE_SIZE);
|
|
|
|
#endif
|
|
|
|
drm_pci_free(dev, phys_obj->handle);
|
|
|
|
kfree(phys_obj);
|
|
|
|
dev_priv->mm.phys_objs[id - 1] = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
void i915_gem_free_all_phys_object(struct drm_device *dev)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2009-01-22 14:58:49 +07:00
|
|
|
for (i = I915_GEM_PHYS_CURSOR_0; i <= I915_MAX_PHYS_OBJECT; i++)
|
2008-12-30 17:31:46 +07:00
|
|
|
i915_gem_free_phys_object(dev, i);
|
|
|
|
}
|
|
|
|
|
|
|
|
void i915_gem_detach_phys_object(struct drm_device *dev,
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_i915_gem_object *obj)
|
2008-12-30 17:31:46 +07:00
|
|
|
{
|
2013-01-24 05:07:38 +07:00
|
|
|
struct address_space *mapping = file_inode(obj->base.filp)->i_mapping;
|
2010-10-28 19:45:36 +07:00
|
|
|
char *vaddr;
|
2008-12-30 17:31:46 +07:00
|
|
|
int i;
|
|
|
|
int page_count;
|
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
if (!obj->phys_obj)
|
2008-12-30 17:31:46 +07:00
|
|
|
return;
|
2010-11-09 02:18:58 +07:00
|
|
|
vaddr = obj->phys_obj->handle->vaddr;
|
2008-12-30 17:31:46 +07:00
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
page_count = obj->base.size / PAGE_SIZE;
|
2008-12-30 17:31:46 +07:00
|
|
|
for (i = 0; i < page_count; i++) {
|
2011-06-28 06:18:18 +07:00
|
|
|
struct page *page = shmem_read_mapping_page(mapping, i);
|
2010-10-28 19:45:36 +07:00
|
|
|
if (!IS_ERR(page)) {
|
|
|
|
char *dst = kmap_atomic(page);
|
|
|
|
memcpy(dst, vaddr + i*PAGE_SIZE, PAGE_SIZE);
|
|
|
|
kunmap_atomic(dst);
|
|
|
|
|
|
|
|
drm_clflush_pages(&page, 1);
|
|
|
|
|
|
|
|
set_page_dirty(page);
|
|
|
|
mark_page_accessed(page);
|
|
|
|
page_cache_release(page);
|
|
|
|
}
|
2008-12-30 17:31:46 +07:00
|
|
|
}
|
2012-11-05 00:21:27 +07:00
|
|
|
i915_gem_chipset_flush(dev);
|
2009-06-18 03:52:49 +07:00
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
obj->phys_obj->cur_obj = NULL;
|
|
|
|
obj->phys_obj = NULL;
|
2008-12-30 17:31:46 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
i915_gem_attach_phys_object(struct drm_device *dev,
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_i915_gem_object *obj,
|
2010-08-07 17:01:39 +07:00
|
|
|
int id,
|
|
|
|
int align)
|
2008-12-30 17:31:46 +07:00
|
|
|
{
|
2013-01-24 05:07:38 +07:00
|
|
|
struct address_space *mapping = file_inode(obj->base.filp)->i_mapping;
|
2008-12-30 17:31:46 +07:00
|
|
|
drm_i915_private_t *dev_priv = dev->dev_private;
|
|
|
|
int ret = 0;
|
|
|
|
int page_count;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (id > I915_MAX_PHYS_OBJECT)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
if (obj->phys_obj) {
|
|
|
|
if (obj->phys_obj->id == id)
|
2008-12-30 17:31:46 +07:00
|
|
|
return 0;
|
|
|
|
i915_gem_detach_phys_object(dev, obj);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* create a new object */
|
|
|
|
if (!dev_priv->mm.phys_objs[id - 1]) {
|
|
|
|
ret = i915_gem_init_phys_object(dev, id,
|
2010-11-09 02:18:58 +07:00
|
|
|
obj->base.size, align);
|
2008-12-30 17:31:46 +07:00
|
|
|
if (ret) {
|
2010-11-09 02:18:58 +07:00
|
|
|
DRM_ERROR("failed to init phys object %d size: %zu\n",
|
|
|
|
id, obj->base.size);
|
2010-10-28 19:45:36 +07:00
|
|
|
return ret;
|
2008-12-30 17:31:46 +07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* bind to the object */
|
2010-11-09 02:18:58 +07:00
|
|
|
obj->phys_obj = dev_priv->mm.phys_objs[id - 1];
|
|
|
|
obj->phys_obj->cur_obj = obj;
|
2008-12-30 17:31:46 +07:00
|
|
|
|
2010-11-09 02:18:58 +07:00
|
|
|
page_count = obj->base.size / PAGE_SIZE;
|
2008-12-30 17:31:46 +07:00
|
|
|
|
|
|
|
for (i = 0; i < page_count; i++) {
|
2010-10-28 19:45:36 +07:00
|
|
|
struct page *page;
|
|
|
|
char *dst, *src;
|
|
|
|
|
2011-06-28 06:18:18 +07:00
|
|
|
page = shmem_read_mapping_page(mapping, i);
|
2010-10-28 19:45:36 +07:00
|
|
|
if (IS_ERR(page))
|
|
|
|
return PTR_ERR(page);
|
2008-12-30 17:31:46 +07:00
|
|
|
|
2010-10-31 04:52:31 +07:00
|
|
|
src = kmap_atomic(page);
|
2010-11-09 02:18:58 +07:00
|
|
|
dst = obj->phys_obj->handle->vaddr + (i * PAGE_SIZE);
|
2008-12-30 17:31:46 +07:00
|
|
|
memcpy(dst, src, PAGE_SIZE);
|
2010-10-27 04:21:51 +07:00
|
|
|
kunmap_atomic(src);
|
2008-12-30 17:31:46 +07:00
|
|
|
|
2010-10-28 19:45:36 +07:00
|
|
|
mark_page_accessed(page);
|
|
|
|
page_cache_release(page);
|
|
|
|
}
|
2009-06-18 03:52:49 +07:00
|
|
|
|
2008-12-30 17:31:46 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2010-11-09 02:18:58 +07:00
|
|
|
i915_gem_phys_pwrite(struct drm_device *dev,
|
|
|
|
struct drm_i915_gem_object *obj,
|
2008-12-30 17:31:46 +07:00
|
|
|
struct drm_i915_gem_pwrite *args,
|
|
|
|
struct drm_file *file_priv)
|
|
|
|
{
|
2010-11-09 02:18:58 +07:00
|
|
|
void *vaddr = obj->phys_obj->handle->vaddr + args->offset;
|
2013-02-22 21:12:51 +07:00
|
|
|
char __user *user_data = to_user_ptr(args->data_ptr);
|
2008-12-30 17:31:46 +07:00
|
|
|
|
2010-11-08 08:12:29 +07:00
|
|
|
if (__copy_from_user_inatomic_nocache(vaddr, user_data, args->size)) {
|
|
|
|
unsigned long unwritten;
|
|
|
|
|
|
|
|
/* The physical object once assigned is fixed for the lifetime
|
|
|
|
* of the obj, so we can safely drop the lock and continue
|
|
|
|
* to access vaddr.
|
|
|
|
*/
|
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
unwritten = copy_from_user(vaddr, user_data, args->size);
|
|
|
|
mutex_lock(&dev->struct_mutex);
|
|
|
|
if (unwritten)
|
|
|
|
return -EFAULT;
|
|
|
|
}
|
2008-12-30 17:31:46 +07:00
|
|
|
|
2012-11-05 00:21:27 +07:00
|
|
|
i915_gem_chipset_flush(dev);
|
2008-12-30 17:31:46 +07:00
|
|
|
return 0;
|
|
|
|
}
|
2009-06-03 14:27:35 +07:00
|
|
|
|
2010-09-24 22:02:42 +07:00
|
|
|
void i915_gem_release(struct drm_device *dev, struct drm_file *file)
|
2009-06-03 14:27:35 +07:00
|
|
|
{
|
2010-09-24 22:02:42 +07:00
|
|
|
struct drm_i915_file_private *file_priv = file->driver_priv;
|
2009-06-03 14:27:35 +07:00
|
|
|
|
drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-25 23:34:56 +07:00
|
|
|
cancel_delayed_work_sync(&file_priv->mm.idle_work);
|
|
|
|
|
2009-06-03 14:27:35 +07:00
|
|
|
/* Clean up our request list when the client is going away, so that
|
|
|
|
* later retire_requests won't dereference our soon-to-be-gone
|
|
|
|
* file_priv.
|
|
|
|
*/
|
2010-09-26 17:03:27 +07:00
|
|
|
spin_lock(&file_priv->mm.lock);
|
2010-09-24 22:02:42 +07:00
|
|
|
while (!list_empty(&file_priv->mm.request_list)) {
|
|
|
|
struct drm_i915_gem_request *request;
|
|
|
|
|
|
|
|
request = list_first_entry(&file_priv->mm.request_list,
|
|
|
|
struct drm_i915_gem_request,
|
|
|
|
client_list);
|
|
|
|
list_del(&request->client_list);
|
|
|
|
request->file_priv = NULL;
|
|
|
|
}
|
2010-09-26 17:03:27 +07:00
|
|
|
spin_unlock(&file_priv->mm.lock);
|
2009-06-03 14:27:35 +07:00
|
|
|
}
|
2009-09-14 22:50:28 +07:00
|
|
|
|
drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-25 23:34:56 +07:00
|
|
|
static void
|
|
|
|
i915_gem_file_idle_work_handler(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct drm_i915_file_private *file_priv =
|
|
|
|
container_of(work, typeof(*file_priv), mm.idle_work.work);
|
|
|
|
|
|
|
|
atomic_set(&file_priv->rps_wait_boost, false);
|
|
|
|
}
|
|
|
|
|
|
|
|
int i915_gem_open(struct drm_device *dev, struct drm_file *file)
|
|
|
|
{
|
|
|
|
struct drm_i915_file_private *file_priv;
|
|
|
|
|
|
|
|
DRM_DEBUG_DRIVER("\n");
|
|
|
|
|
|
|
|
file_priv = kzalloc(sizeof(*file_priv), GFP_KERNEL);
|
|
|
|
if (!file_priv)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
file->driver_priv = file_priv;
|
|
|
|
file_priv->dev_priv = dev->dev_private;
|
|
|
|
|
|
|
|
spin_lock_init(&file_priv->mm.lock);
|
|
|
|
INIT_LIST_HEAD(&file_priv->mm.request_list);
|
|
|
|
INIT_DELAYED_WORK(&file_priv->mm.idle_work,
|
|
|
|
i915_gem_file_idle_work_handler);
|
|
|
|
|
|
|
|
idr_init(&file_priv->context_idr);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-11-21 20:04:04 +07:00
|
|
|
static bool mutex_is_locked_by(struct mutex *mutex, struct task_struct *task)
|
|
|
|
{
|
|
|
|
if (!mutex_is_locked(mutex))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_MUTEXES)
|
|
|
|
return mutex->owner == task;
|
|
|
|
#else
|
|
|
|
/* Since UP may be pre-empted, we cannot assume that we own the lock */
|
|
|
|
return false;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
drivers: convert shrinkers to new count/scan API
Convert the driver shrinkers to the new API. Most changes are compile
tested only because I either don't have the hardware or it's staging
stuff.
FWIW, the md and android code is pretty good, but the rest of it makes me
want to claw my eyes out. The amount of broken code I just encountered is
mind boggling. I've added comments explaining what is broken, but I fear
that some of the code would be best dealt with by being dragged behind the
bike shed, burying in mud up to it's neck and then run over repeatedly
with a blunt lawn mower.
Special mention goes to the zcache/zcache2 drivers. They can't co-exist
in the build at the same time, they are under different menu options in
menuconfig, they only show up when you've got the right set of mm
subsystem options configured and so even compile testing is an exercise in
pulling teeth. And that doesn't even take into account the horrible,
broken code...
[glommer@openvz.org: fixes for i915, android lowmem, zcache, bcache]
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Glauber Costa <glommer@openvz.org>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Rientjes <rientjes@google.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: J. Bruce Fields <bfields@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-28 07:18:11 +07:00
|
|
|
static unsigned long
|
|
|
|
i915_gem_inactive_count(struct shrinker *shrinker, struct shrink_control *sc)
|
2009-09-14 22:50:28 +07:00
|
|
|
{
|
2010-10-28 18:51:39 +07:00
|
|
|
struct drm_i915_private *dev_priv =
|
|
|
|
container_of(shrinker,
|
|
|
|
struct drm_i915_private,
|
|
|
|
mm.inactive_shrinker);
|
|
|
|
struct drm_device *dev = dev_priv->dev;
|
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 16:40:46 +07:00
|
|
|
struct drm_i915_gem_object *obj;
|
2012-11-21 20:04:04 +07:00
|
|
|
bool unlock = true;
|
drivers: convert shrinkers to new count/scan API
Convert the driver shrinkers to the new API. Most changes are compile
tested only because I either don't have the hardware or it's staging
stuff.
FWIW, the md and android code is pretty good, but the rest of it makes me
want to claw my eyes out. The amount of broken code I just encountered is
mind boggling. I've added comments explaining what is broken, but I fear
that some of the code would be best dealt with by being dragged behind the
bike shed, burying in mud up to it's neck and then run over repeatedly
with a blunt lawn mower.
Special mention goes to the zcache/zcache2 drivers. They can't co-exist
in the build at the same time, they are under different menu options in
menuconfig, they only show up when you've got the right set of mm
subsystem options configured and so even compile testing is an exercise in
pulling teeth. And that doesn't even take into account the horrible,
broken code...
[glommer@openvz.org: fixes for i915, android lowmem, zcache, bcache]
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Glauber Costa <glommer@openvz.org>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Rientjes <rientjes@google.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: J. Bruce Fields <bfields@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-28 07:18:11 +07:00
|
|
|
unsigned long count;
|
2010-10-28 18:51:39 +07:00
|
|
|
|
2012-11-21 20:04:04 +07:00
|
|
|
if (!mutex_trylock(&dev->struct_mutex)) {
|
|
|
|
if (!mutex_is_locked_by(&dev->struct_mutex, current))
|
2013-09-25 19:00:02 +07:00
|
|
|
return 0;
|
2012-11-21 20:04:04 +07:00
|
|
|
|
2012-12-19 20:33:45 +07:00
|
|
|
if (dev_priv->mm.shrinker_no_lock_stealing)
|
2013-09-25 19:00:02 +07:00
|
|
|
return 0;
|
2012-12-19 20:33:45 +07:00
|
|
|
|
2012-11-21 20:04:04 +07:00
|
|
|
unlock = false;
|
|
|
|
}
|
2009-09-14 22:50:28 +07:00
|
|
|
|
drivers: convert shrinkers to new count/scan API
Convert the driver shrinkers to the new API. Most changes are compile
tested only because I either don't have the hardware or it's staging
stuff.
FWIW, the md and android code is pretty good, but the rest of it makes me
want to claw my eyes out. The amount of broken code I just encountered is
mind boggling. I've added comments explaining what is broken, but I fear
that some of the code would be best dealt with by being dragged behind the
bike shed, burying in mud up to it's neck and then run over repeatedly
with a blunt lawn mower.
Special mention goes to the zcache/zcache2 drivers. They can't co-exist
in the build at the same time, they are under different menu options in
menuconfig, they only show up when you've got the right set of mm
subsystem options configured and so even compile testing is an exercise in
pulling teeth. And that doesn't even take into account the horrible,
broken code...
[glommer@openvz.org: fixes for i915, android lowmem, zcache, bcache]
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Glauber Costa <glommer@openvz.org>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Rientjes <rientjes@google.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: J. Bruce Fields <bfields@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-28 07:18:11 +07:00
|
|
|
count = 0;
|
2013-06-01 01:28:48 +07:00
|
|
|
list_for_each_entry(obj, &dev_priv->mm.unbound_list, global_list)
|
2012-09-05 03:02:54 +07:00
|
|
|
if (obj->pages_pin_count == 0)
|
drivers: convert shrinkers to new count/scan API
Convert the driver shrinkers to the new API. Most changes are compile
tested only because I either don't have the hardware or it's staging
stuff.
FWIW, the md and android code is pretty good, but the rest of it makes me
want to claw my eyes out. The amount of broken code I just encountered is
mind boggling. I've added comments explaining what is broken, but I fear
that some of the code would be best dealt with by being dragged behind the
bike shed, burying in mud up to it's neck and then run over repeatedly
with a blunt lawn mower.
Special mention goes to the zcache/zcache2 drivers. They can't co-exist
in the build at the same time, they are under different menu options in
menuconfig, they only show up when you've got the right set of mm
subsystem options configured and so even compile testing is an exercise in
pulling teeth. And that doesn't even take into account the horrible,
broken code...
[glommer@openvz.org: fixes for i915, android lowmem, zcache, bcache]
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Glauber Costa <glommer@openvz.org>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Rientjes <rientjes@google.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: J. Bruce Fields <bfields@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-28 07:18:11 +07:00
|
|
|
count += obj->base.size >> PAGE_SHIFT;
|
2013-08-01 06:59:57 +07:00
|
|
|
|
|
|
|
list_for_each_entry(obj, &dev_priv->mm.bound_list, global_list) {
|
|
|
|
if (obj->active)
|
|
|
|
continue;
|
|
|
|
|
2012-09-05 03:02:54 +07:00
|
|
|
if (obj->pin_count == 0 && obj->pages_pin_count == 0)
|
drivers: convert shrinkers to new count/scan API
Convert the driver shrinkers to the new API. Most changes are compile
tested only because I either don't have the hardware or it's staging
stuff.
FWIW, the md and android code is pretty good, but the rest of it makes me
want to claw my eyes out. The amount of broken code I just encountered is
mind boggling. I've added comments explaining what is broken, but I fear
that some of the code would be best dealt with by being dragged behind the
bike shed, burying in mud up to it's neck and then run over repeatedly
with a blunt lawn mower.
Special mention goes to the zcache/zcache2 drivers. They can't co-exist
in the build at the same time, they are under different menu options in
menuconfig, they only show up when you've got the right set of mm
subsystem options configured and so even compile testing is an exercise in
pulling teeth. And that doesn't even take into account the horrible,
broken code...
[glommer@openvz.org: fixes for i915, android lowmem, zcache, bcache]
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Glauber Costa <glommer@openvz.org>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Rientjes <rientjes@google.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: J. Bruce Fields <bfields@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-28 07:18:11 +07:00
|
|
|
count += obj->base.size >> PAGE_SHIFT;
|
2013-08-01 06:59:57 +07:00
|
|
|
}
|
2010-10-28 18:51:39 +07:00
|
|
|
|
2012-11-21 20:04:04 +07:00
|
|
|
if (unlock)
|
|
|
|
mutex_unlock(&dev->struct_mutex);
|
2013-10-04 16:33:00 +07:00
|
|
|
|
drivers: convert shrinkers to new count/scan API
Convert the driver shrinkers to the new API. Most changes are compile
tested only because I either don't have the hardware or it's staging
stuff.
FWIW, the md and android code is pretty good, but the rest of it makes me
want to claw my eyes out. The amount of broken code I just encountered is
mind boggling. I've added comments explaining what is broken, but I fear
that some of the code would be best dealt with by being dragged behind the
bike shed, burying in mud up to it's neck and then run over repeatedly
with a blunt lawn mower.
Special mention goes to the zcache/zcache2 drivers. They can't co-exist
in the build at the same time, they are under different menu options in
menuconfig, they only show up when you've got the right set of mm
subsystem options configured and so even compile testing is an exercise in
pulling teeth. And that doesn't even take into account the horrible,
broken code...
[glommer@openvz.org: fixes for i915, android lowmem, zcache, bcache]
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Glauber Costa <glommer@openvz.org>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Rientjes <rientjes@google.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: J. Bruce Fields <bfields@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-28 07:18:11 +07:00
|
|
|
return count;
|
2009-09-14 22:50:28 +07:00
|
|
|
}
|
2013-08-01 06:59:56 +07:00
|
|
|
|
|
|
|
/* All the new VM stuff */
|
|
|
|
unsigned long i915_gem_obj_offset(struct drm_i915_gem_object *o,
|
|
|
|
struct i915_address_space *vm)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = o->base.dev->dev_private;
|
|
|
|
struct i915_vma *vma;
|
|
|
|
|
|
|
|
if (vm == &dev_priv->mm.aliasing_ppgtt->base)
|
|
|
|
vm = &dev_priv->gtt.base;
|
|
|
|
|
|
|
|
BUG_ON(list_empty(&o->vma_list));
|
|
|
|
list_for_each_entry(vma, &o->vma_list, vma_link) {
|
|
|
|
if (vma->vm == vm)
|
|
|
|
return vma->node.start;
|
|
|
|
|
|
|
|
}
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool i915_gem_obj_bound(struct drm_i915_gem_object *o,
|
|
|
|
struct i915_address_space *vm)
|
|
|
|
{
|
|
|
|
struct i915_vma *vma;
|
|
|
|
|
|
|
|
list_for_each_entry(vma, &o->vma_list, vma_link)
|
2013-08-01 07:00:16 +07:00
|
|
|
if (vma->vm == vm && drm_mm_node_allocated(&vma->node))
|
2013-08-01 06:59:56 +07:00
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool i915_gem_obj_bound_any(struct drm_i915_gem_object *o)
|
|
|
|
{
|
2013-09-10 17:27:37 +07:00
|
|
|
struct i915_vma *vma;
|
2013-08-01 06:59:56 +07:00
|
|
|
|
2013-09-10 17:27:37 +07:00
|
|
|
list_for_each_entry(vma, &o->vma_list, vma_link)
|
|
|
|
if (drm_mm_node_allocated(&vma->node))
|
2013-08-01 06:59:56 +07:00
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned long i915_gem_obj_size(struct drm_i915_gem_object *o,
|
|
|
|
struct i915_address_space *vm)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = o->base.dev->dev_private;
|
|
|
|
struct i915_vma *vma;
|
|
|
|
|
|
|
|
if (vm == &dev_priv->mm.aliasing_ppgtt->base)
|
|
|
|
vm = &dev_priv->gtt.base;
|
|
|
|
|
|
|
|
BUG_ON(list_empty(&o->vma_list));
|
|
|
|
|
|
|
|
list_for_each_entry(vma, &o->vma_list, vma_link)
|
|
|
|
if (vma->vm == vm)
|
|
|
|
return vma->node.size;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
drivers: convert shrinkers to new count/scan API
Convert the driver shrinkers to the new API. Most changes are compile
tested only because I either don't have the hardware or it's staging
stuff.
FWIW, the md and android code is pretty good, but the rest of it makes me
want to claw my eyes out. The amount of broken code I just encountered is
mind boggling. I've added comments explaining what is broken, but I fear
that some of the code would be best dealt with by being dragged behind the
bike shed, burying in mud up to it's neck and then run over repeatedly
with a blunt lawn mower.
Special mention goes to the zcache/zcache2 drivers. They can't co-exist
in the build at the same time, they are under different menu options in
menuconfig, they only show up when you've got the right set of mm
subsystem options configured and so even compile testing is an exercise in
pulling teeth. And that doesn't even take into account the horrible,
broken code...
[glommer@openvz.org: fixes for i915, android lowmem, zcache, bcache]
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Glauber Costa <glommer@openvz.org>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Rientjes <rientjes@google.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: J. Bruce Fields <bfields@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-28 07:18:11 +07:00
|
|
|
static unsigned long
|
|
|
|
i915_gem_inactive_scan(struct shrinker *shrinker, struct shrink_control *sc)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv =
|
|
|
|
container_of(shrinker,
|
|
|
|
struct drm_i915_private,
|
|
|
|
mm.inactive_shrinker);
|
|
|
|
struct drm_device *dev = dev_priv->dev;
|
|
|
|
unsigned long freed;
|
|
|
|
bool unlock = true;
|
|
|
|
|
|
|
|
if (!mutex_trylock(&dev->struct_mutex)) {
|
|
|
|
if (!mutex_is_locked_by(&dev->struct_mutex, current))
|
2013-09-25 19:00:02 +07:00
|
|
|
return SHRINK_STOP;
|
drivers: convert shrinkers to new count/scan API
Convert the driver shrinkers to the new API. Most changes are compile
tested only because I either don't have the hardware or it's staging
stuff.
FWIW, the md and android code is pretty good, but the rest of it makes me
want to claw my eyes out. The amount of broken code I just encountered is
mind boggling. I've added comments explaining what is broken, but I fear
that some of the code would be best dealt with by being dragged behind the
bike shed, burying in mud up to it's neck and then run over repeatedly
with a blunt lawn mower.
Special mention goes to the zcache/zcache2 drivers. They can't co-exist
in the build at the same time, they are under different menu options in
menuconfig, they only show up when you've got the right set of mm
subsystem options configured and so even compile testing is an exercise in
pulling teeth. And that doesn't even take into account the horrible,
broken code...
[glommer@openvz.org: fixes for i915, android lowmem, zcache, bcache]
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Glauber Costa <glommer@openvz.org>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Rientjes <rientjes@google.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: J. Bruce Fields <bfields@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-28 07:18:11 +07:00
|
|
|
|
|
|
|
if (dev_priv->mm.shrinker_no_lock_stealing)
|
2013-09-25 19:00:02 +07:00
|
|
|
return SHRINK_STOP;
|
drivers: convert shrinkers to new count/scan API
Convert the driver shrinkers to the new API. Most changes are compile
tested only because I either don't have the hardware or it's staging
stuff.
FWIW, the md and android code is pretty good, but the rest of it makes me
want to claw my eyes out. The amount of broken code I just encountered is
mind boggling. I've added comments explaining what is broken, but I fear
that some of the code would be best dealt with by being dragged behind the
bike shed, burying in mud up to it's neck and then run over repeatedly
with a blunt lawn mower.
Special mention goes to the zcache/zcache2 drivers. They can't co-exist
in the build at the same time, they are under different menu options in
menuconfig, they only show up when you've got the right set of mm
subsystem options configured and so even compile testing is an exercise in
pulling teeth. And that doesn't even take into account the horrible,
broken code...
[glommer@openvz.org: fixes for i915, android lowmem, zcache, bcache]
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Glauber Costa <glommer@openvz.org>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Rientjes <rientjes@google.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: J. Bruce Fields <bfields@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-28 07:18:11 +07:00
|
|
|
|
|
|
|
unlock = false;
|
|
|
|
}
|
|
|
|
|
2013-10-04 16:33:00 +07:00
|
|
|
freed = i915_gem_purge(dev_priv, sc->nr_to_scan);
|
|
|
|
if (freed < sc->nr_to_scan)
|
|
|
|
freed += __i915_gem_shrink(dev_priv,
|
|
|
|
sc->nr_to_scan - freed,
|
|
|
|
false);
|
|
|
|
if (freed < sc->nr_to_scan)
|
drivers: convert shrinkers to new count/scan API
Convert the driver shrinkers to the new API. Most changes are compile
tested only because I either don't have the hardware or it's staging
stuff.
FWIW, the md and android code is pretty good, but the rest of it makes me
want to claw my eyes out. The amount of broken code I just encountered is
mind boggling. I've added comments explaining what is broken, but I fear
that some of the code would be best dealt with by being dragged behind the
bike shed, burying in mud up to it's neck and then run over repeatedly
with a blunt lawn mower.
Special mention goes to the zcache/zcache2 drivers. They can't co-exist
in the build at the same time, they are under different menu options in
menuconfig, they only show up when you've got the right set of mm
subsystem options configured and so even compile testing is an exercise in
pulling teeth. And that doesn't even take into account the horrible,
broken code...
[glommer@openvz.org: fixes for i915, android lowmem, zcache, bcache]
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Glauber Costa <glommer@openvz.org>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Rientjes <rientjes@google.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: J. Bruce Fields <bfields@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-28 07:18:11 +07:00
|
|
|
freed += i915_gem_shrink_all(dev_priv);
|
|
|
|
|
|
|
|
if (unlock)
|
|
|
|
mutex_unlock(&dev->struct_mutex);
|
2013-10-04 16:33:00 +07:00
|
|
|
|
drivers: convert shrinkers to new count/scan API
Convert the driver shrinkers to the new API. Most changes are compile
tested only because I either don't have the hardware or it's staging
stuff.
FWIW, the md and android code is pretty good, but the rest of it makes me
want to claw my eyes out. The amount of broken code I just encountered is
mind boggling. I've added comments explaining what is broken, but I fear
that some of the code would be best dealt with by being dragged behind the
bike shed, burying in mud up to it's neck and then run over repeatedly
with a blunt lawn mower.
Special mention goes to the zcache/zcache2 drivers. They can't co-exist
in the build at the same time, they are under different menu options in
menuconfig, they only show up when you've got the right set of mm
subsystem options configured and so even compile testing is an exercise in
pulling teeth. And that doesn't even take into account the horrible,
broken code...
[glommer@openvz.org: fixes for i915, android lowmem, zcache, bcache]
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Glauber Costa <glommer@openvz.org>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Rientjes <rientjes@google.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: J. Bruce Fields <bfields@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kent Overstreet <koverstreet@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-28 07:18:11 +07:00
|
|
|
return freed;
|
|
|
|
}
|
2013-09-24 23:57:57 +07:00
|
|
|
|
|
|
|
struct i915_vma *i915_gem_obj_to_ggtt(struct drm_i915_gem_object *obj)
|
|
|
|
{
|
|
|
|
struct i915_vma *vma;
|
|
|
|
|
|
|
|
if (WARN_ON(list_empty(&obj->vma_list)))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
vma = list_first_entry(&obj->vma_list, typeof(*vma), vma_link);
|
|
|
|
if (WARN_ON(vma->vm != obj_to_ggtt(obj)))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return vma;
|
|
|
|
}
|